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PREFACE 


The purpose of the MODIS Information, Data, and Control System (MIDACS) Operations 
Concepts Document is to provide a basis for the mutual understanding between the users 
and the designers of the MIDACS, including the requirements, operating environment, 
external interfaces, and development plan. In defining the concepts and scope of the 
system, this document will describe how MIDACS will operate as an element of the Earth 
Observing System (EOS) within the EosDIS environment. This version of the Operations 
Concept follows the earlier release of a preliminary version. The individual operations 
concepts for planning and scheduling, control and monitoring, data acquisition and 
processing, calibration and validation, data archive and distribution, and user access do 
not yet fully represent the requirements of the data system needed to achieve the scien- 
tific objectives of the MODIS instruments and science team. Indeed, the team members 
have not yet been selected and the team has not yet been formed. However, it has been 
possible to develop the operations concepts based on the present concept of EosDIS, the 
Level-I and Level-II Functional Requirements Documents, and through interviews and 
meetings with key members of the science community. The operations concepts have 
been exercised through the application of representative scenarios. 

The study team is indebted to: Wayne Esaias, Chris Justice, and Joel Susskind for 
detailed information regarding the science requirements; Bill Barnes, John Barker, and 
Bruce Guenther for information regarding MODIS instrument concepts; H. Lee Kyle, and 
Dick Stonesifer for their insight into aspects of data processing, instrument control, and 
data storage; and to A1 Fleig for his assistance in applying the guidelines being set forth 
by EosDIS. 
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1. INTRODUCTION 


The global Earth Observing System (EOS) is made up of the U.S. and its international 
partners. The data processing, distribution, and management element, the Data and 
Information System, under the NASA EOS Project, are called the EosDIS. The EosDIS is 
planned as a remote sensing system providing data acquisition, receipt, processing, 
management, and distribution support for the Earth observation data acquired by the 
instruments on board the NASA Polar Orbiting Platform (NPOP). Two of the many 
instruments scheduled to be on the first NPOP (NPOP-1) are the Moderate Resolution 
Imaging Spectrometer-N (MODIS-N) and MODIS-T instruments. In order to support the 
MODIS instrument complement, an EosDIS-unique element is necessary. This unique 
element is the MODIS Information Data and Control System (MIDACS). 

1.1 PURPOSE 

The purpose of the MODIS Information, Data, and Control System (MIDACS) Operations 
Concepts Document is to provide a basis for the mutual understanding between the users 
and the designers of the MIDACS, including the requirements, operating environment, 
external interfaces, and development plan. In defining the concepts and scope of the 
system, this document will describe how MIDACS will operate as an element of the EOS 
within the EosDIS environment. 

1.2 SCOPE 

The MIDACS fulfills the responsibilities of instrument monitoring and control, as well as 
data acquisition, management, production, certification, and distribution. In order to 
design the MODIS data system to efficiently and reliably fulfill each of these functions, 
the system’s operational concepts must be clearly stated. It is recognized that these 
concepts will evolve as information is compiled, the science team formed, and the instru- 
ment design refined. This document will mature in response to evolutions in the 
scientific and functional requirements. In this preliminary report all MIDACS concepts 
are addressed, although some specific facility concepts are not fully identified. These 
will be completed in a later draft. 

1.3 MODIS INSTRUMENT 

The MODIS instrument will be composed of two components: the MODIS-T, a "tiltable" 
cross-track scanner, and the MODIS-N, a nadir-viewing cross-track scanner. As cur- 
rently envisioned, the instruments will provide multi-year, continuous terrestrial coverage 
across a nearly 2000-kilometer swath with 104 channels covering the visible, 
near-infrared, and thermal infrared spectral regions. The channels have been selected to 
provide terrestrial, oceanographic, and meteorological observations at spatial resolutions 
ranging from one kilometer to 250 meters at nadir. 

As a consequence of the design of MODIS, a high data rate and an extremely large data 
archive volume are anticipated. Furthermore, specific aspects of the EosDIS combine to 
shape the processing requirements for the MODIS data system; in particular, the release 
of certified data products in accessible, long-term archives. 

1.4 REFERENCES AND APPLICABLE DOCUMENTS 

a. EosDIS Baseline Report, CTA, July 29, 1988. 
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b. Earth Observing System Data and Information System Report of the EOS Data 
Panel, Vol. Ila, NASA, 1986. 

c. EosDIS Control Center Concepts, Vol. 2.1, February 25, 1988. 

d. EosDIS Pre-Phase B System Design Concept Report, CTA, January 1988. 

e. EosDIS Control Center Concepts, EosDIS Planning and Scheduling Scenario, 
October 11, 1988, Code 510.1/Steve Tompkins. 

2. MODIS OPERATING ENVIRONMENT 

2.1 MIDACS/EosDIS ENVIRONMENT 

MODIS has been designated as a GSFC facility instrument on the first NASA polar 
orbiting platform, NPOP-1, scheduled for launch in 1996. It is the responsibility of 
NASA to provide a ground system by that time which will control the operation of the 
MODIS instrument on board the platform and perform the data acquisition, processing, 
and distribution functions to serve the user community. 

NASA’s Goddard Space Flight Center (GSFC) is responsible for the design and develop- 
ment of the MODIS ground system, MIDACS. This ground system will be one of the 
elements operating in the context of the overall EosDIS. The EosDIS will be responsible 
for the end-to-end data flows involving the Tracking and Data Relay Satellite System 
(TDRSS) and its ground terminals at White Sands, the various EOS ground systems, and 
the users. Figure 1 describes the EosDIS environment under which the MIDACS will 
operate. The following sections provide a brief description for each of the systems in 
the EosDIS and MIDACS environments. 

2.1.1 MODIS Flight Data System 

A flight data system will be available for each instrument on the EOS platform. The 
functions of the flight data system include instrument commanding and collection of 
observation data. For MODIS, the platform local area network (LAN) will provide 
support for the transfer of science, engineering, and ancillary data as well as the 
platform core ancillary data, command loads, and other management functions. Data will 
be encapsulated by the MODIS instrument in formatted packets based on recommendations 
of the Consultative Committee for Space Data Systems (CCSDS) for transfer on the LAN. 

2.1.2 EOS Platform Flight System 

The platform architecture is based on orbit replacement units (ORUs) which contain 
specific payloads, of which MODIS is one, that are connected to the LAN. The control 
of MODIS and other instruments are provided by a data management system. This 
control encompasses allocation of operation resources, timing functions, and common 
services such as on-board storage. The platform flight system will provide for transmis- 
sion and reception of all data to and from the ground via the TDRSS. 

2.1.3 External Interfaces 

Figure 2 provides a context diagram of the MIDACS and shows the external elements it 
will interface with. The following describe in detail the external facilities that interface 
with the MIDACS. 
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Figure 1. The MODIS Data System in the EosDIS Environment 
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Figure 2. MIDACS Context Diagram 







2. 1.3.1 EOS Mission Operations Center (EMOC) 

The EMOC will coordinate the operation of EOS instruments on the U.S. platforms and 
will provide the primary point of contact between the EOS mission and the Space Station 
Information System (SSIS) for mission operations. Located at GSFC, the EMOC will 
consist of a project team that includes the Project Operations Director (POD) and the 
Assistant Project Scientist (APS). 

The EMOC will provide the EOS schedule based on the science plan from the Investigator 
Working Group (IWG), resource availability received from the Platform Support Center 
(PSC), and planning support information from the Flight Dynamics Facility (FDF). (A 
portion of platform resources may be reserved for NOAA.) The EMOC will not be 
responsible for scheduling NOAA operations but will coordinate with NOAA for the 
scheduling of potentially conflicting operations between NOAA instruments and MODIS. 
The sub-allocations of the remaining resources and guidelines for scheduling will be 
provided by the EMOC to the MODIS Instrument Control Center (ICC) for scheduling 
instrument operations. The EMOC will receive the schedule requests from the ICC, 
resolve conflicts between instruments, and provide a single request for platform resources 
to the PSC. This process will be iterated until a final conflict-free schedule is distri- 
buted to the ICC. The schedule is then stable but will be able to accommodate perturba- 
tions caused by unplanned changes in resource availability, anomalies, and/or Targets of 
Opportunity (TOO). 

The EMOC will monitor operations by processing (and displaying) instrument status 
information received from the ICC and the ancillary data received from the Data 
Handling Center (DHC). If a safety problem is detected, the EMOC, the PSC, or the ICC 
can send a saving command sequence to the instrument. This will be a coordinated 
action. The EosDIS will monitor the data distribution systems in order to detect 
problems in delivering EOS data. 

A log of EMOC operations (including commands received from the ICCs) will be main- 
tained and archived. These archives, coordinated and managed by the EMOC, will be 
used to support future anomaly analysis and/or science data analysis. The EMOC will 
provide reports on EOS operations to the EOS project, and it will report the science 
plan implementation status to the IWG. 

2. 1.3.2 Data Handling Center (DHC) 

The DHC will routinely perform Level-0 Processing (LZP) for all EOS payload data. The 
DHC is likely to be a distributed function whose location(s) and architecture have not 
been resolved, but these choices are internal to the Customer Data and Operations 
System (CDOS) project. As a backup to the Command and Data Acquisition (CDA) link, 
full resolution operational data will be routinely transmitted via the TDRSS through the 
Data Interface Facility (DIF) to the DHC as part of the downlink data stream. Some or 
all of these data may receive LZP to satisfy unique requirements of the research 
community. 

At the DHC, Virtual Channel Data Units (VCDU) will be converted into constituent 
packets; data will be time ordered and, if necessary, reversed; the data will be organized 
into Level-0 data sets for temporary storage; payload engineering data packets and other 
designated high-priority data packets will be stripped off and forwarded to the MIDACS; 
and ancillary data support services will be performed. Ancillary data transformations 
(e.g., coordinate transformations) and calibrations may be made (if preferred standard 
computations are not available in the on-board ancillary packets) and enhanced ancillary 
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data packets produced. These production and ancillary data sets will be made available 
to the MIDACS. Level-0 data will be forwarded to the MIDACS within 24 hours of 
observation in accordance with prearranged schedules and routing; however, near-real- 
time data supporting field experiments will be forwarded within six hours, perhaps 
without all LZP performed. 

The DHC must also be able to detect, process, and route engineering and priority 
playback data to the appropriate user in a timely manner. Real-time engineering data 
are engineering/housekeeping data transmitted during a TDRSS contact period. The data 
will include both platform and payload information. They should be routed in a pass- 
through mode that minimizes delay to the MIDACS. Priority playback data consist of 
platform or payload engineering data and selected science data recorded on-board that 
are required in less than the normal turn around time from the DHC. Priority playback 
data are forwarded to the MIDACS. 

The DHC will also be responsible for the quality control of ancillary data received from 
the platform. Ancillary data values will be checked against high and low limits and in 
coordination with the FDF; onboard orbit/attitude parameters will be validated by 
comparing these data with orbit and attitude reference profiles. The DHC will make all 
ancillary data available to the MIDACS, and it will store this information for a minimum 
of two years. The format of ancillary data and the checks to be performed will be 
developed by the Ancillary Data Support Working Group currently meeting at GSFC. 

2.1. 3.3 Information Management Center (IMC) 

The Information Management Center (IMC) is treated in this report as an external 
interface. It will be the clearing house for all information about EOS data. This 
function will provide multi-user one-stop connectivity for EOS data information including 
directory, metadata, and catalog data, as well as access to actual data sets and browse 
data sets. The IMC would maintain cognizance over all data requests and will ensure 
their successful and timely fulfillment. It should be emphasized that only EOS catalog 
and metadata are stored at the IMC. 

All EosDIS users will access the IMC via an EosDIS network interface. This feature 
must support connectivity with a variety of government and commercial networks as well 
as several communications protocols and a variety of user terminals. All of this must be 
accomplished while providing the user with a simple, "friendly" menu-driven interface 
protocol to allow him to request his desired information. All data request and response 
queries will be via this link; actual data set transfer will be directly from the data 
repository to the user. 

A variety of catalogs/directories will be maintained on-line, ordered by date/time, 
instrument (including different channels/ resolutions/operating modes), environmental 
parameter, geographical location, feature detection, data location, etc. It is anticipated 
that most requests can be filled from this subsystem in an automatic fashion, with 
manual intervention available for unusual requests. Response time to a user should be 
timely, and will be limited by the search capability of the system. EosDIS will be unique 
in the environmental data world in its goal of making multi-discipline data available to a 
world-wide group of scientists. In order to do this effectively, a sophisticated data 
management system will be required with an ability to track the progress of all new EOS 
data every day as well as previously recorded and processed EOS data. 
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Request for data sets will be sent to the appropriate archive facility and status informa- 
tion received. The IMC will also feature an On-line Documentation Subsystem to support 
EosDIS requirements to: 

a. Maintain on-line documentation containing information on EosDIS requirements, 
specifications, command loads, engineering data and diagnostics, test and 
calibration procedures, operations software algorithms, validation results, 
scientific papers and system operations procedures. 

b. Monitor and report on program, platform and payload status. 

Documentation and status information will be received from all elements of the EosDIS 
and maintained on-line for access by the users. 

A final feature of the IMC will be a project billing and accounting function. Users 
desiring EOS data will need to establish an account with the IMC in order to obtain 
services, information, and data. The method of operating this feature will be determined 
at a later date. 

2.1. 3.4 Tracking and Data Relay Satellite System (TDRSS) 

The TDRSS provides the uplink and downlink capability for the EOS platform. On the 
average, a platform should have access to the TDRSS for about one-third of its orbit. 

The MODIS data will be downlinked by the TDRSS to the White Sands Ground Terminal 
(WSGT) for routing to the MIDACS. Uplinking through TDRSS will be used to support 
commanding of the instrument. In order to support specific real-time instrument 
requirements and the timeliness requirements of certain field experiments, the TDRSS 
must be responsive to the MIDACS when scheduling access times. 

2.1.3. 5 Data Interface Facility (DIF) 

The DIF provides data communication, data buffering, and data routing between the space 
network and ground data network. 

2. 1.3. 6 Platform Support Center (PSC) 

The PSC is a proposed GSFC facility under the CDOS that will provide mission control 
support for a variety of space programs at GSFC. The PSC will perform standard control 
center functions to monitor and control the platform operations. The PSC will be 
involved in the planning and scheduling functions for EOS payloads, as well as in all 
aspects of planning, scheduling, commanding, and telemetry monitoring of the platform 
core. 

2. 1.3.7 Remote Users 

Users, except the MODIS science team leader and science team members, will interface 
with the MIDACS through the IMC. The MODIS science team members have the option 
of interfacing through the IMC, but they will also have direct contacts with each of the 
MIDACS elements. 

2. 1.3.8 Long-Term Archives 

Several centers will serve as long-term storage areas for MODIS data. The data sets 
archived will contain high-level information. The National Space Science Data Center 
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(NSSDC) currently serves as a long-term archiving and distribution center for data 
obtained on NASA Space and Earth Science flight investigations and will provide for the 
long-term storage of atmospheric data. The NSSDC develops and performs a variety of 
services to enhance the scientific return in these missions. NOAA will provide for the 
long-term storage of oceanographic data. The EROS data center will provide long-term 
storage for land data. 

2.2 FUNCTIONAL DESCRIPTION OF MIDACS 

The following sections are a list of internal elements of MIDACS and the respective 
functions which support the MODIS instrument. 

2.2.1 Instrument Support Terminal (1ST) 

The 1ST is essentially a workstation connected to the ICC. It gives the science team 
leader or designated team members by the team leader access to the engineering data or 
quick-look science subsets of the payload in order to support instrument integrity 
functions and/or to initiate commands and plans for specialized conditions. 

2.2.2 Instrument Control Center (ICC) 

This center is responsible for the ground control operation of the MODIS instrument on 
board the platform. It is assumed that there is one ICC dedicated to the MODIS 
instrument. The ICC will support the instrument planning, scheduling, commanding, and 
status monitoring of MODIS. 

2.2.3 Team Member Computing Facility (TMCF) 

A science team member will be responsible for the development and maintenance of the 
algorithms for the production of data sets. The TMCF will be a distributed network of 
project-provided computing resources to be used in the development and testing of 
algorithms, the production of special data sets, and the assessment of data quality 
including calibration, earth location, certification, and validation. 

One of the network nodes will be located at the GSFC. Because MODIS will be a 
Goddard Facility Instrument, the GSFC TMCF is unique within TMCF in the following 
aspects: 

a. Several MODIS science team members, each with their own computing facilities 
(e.g., workstations), will reside there. 

b. The MODIS science team leader will be at this node. 

c. The MODIS Calibration Support Team (CST) will have several workstations at 
this node. 

d. A group of computer scientists at the GSFC node will aid MODIS science team 
members in making their computer codes more efficient and in compliance with 
EosDIS software standards. They will also develop programs of general utility 
to all MODIS science team members. 
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2.2.4 Central Data Handling Facility (CDHF) 

The CDHF has the responsibility of receiving instrument data and generating standard 
products for the user at predetermined levels of processing. The levels of data to be 
produced include Level-1 A (reversible to Level-0), Level-IB (calibrated and Earth-located 
radiances), Level-2 (geophysical parameters), Level-3 (gridded and averaged products), and 
Level-4 (scientific applications and comparisons to non-MODIS products). 

2.2.5 Data Archive and Distribution System (DADS) 

The DADS will provide for the storage, management, and distribution of processed data 
sets, catalogs, and directories for data supplied by the CDHF and others. It provides an 
interface to the users for distribution of requested products. 

2.3 PERSONNEL AND OPERATIONS TEAMS IN THE MIDACS 

This subsection defines six categories of personnel required for conducting mission 
operations in the MIDACS operations environment. They are: 

a. MODIS science team and team leader 

b. Instrument Operations Team (IOT) 

c. MODIS CST 

d. Product Support Analyst 

e. System Operators 

f. Data Clerks 

These teams represent a wide range of job responsibility, technical expertise, and 
authority. In order to successfully accomplish the MODIS functions described in Section 
2, a set of roles and responsibilities for each of the teams and interactions between them 
is presented. An additional discussion on the classification of science users is included 
in this section. 

2.3.1 MODIS Science Team 

The MODIS science team, under the direction of the MODIS science team leader, will be 
staffed by scientists having well-established expertise in the use of multispectral imagery 
to solve scientific problems related to the environment. They will be selected by NASA 
based upon the proposals they submitted in response to the NASA Announcement of 
Opportunity (AO) for EOS. This team has the following roles and responsibilities: 

a. The science team is responsible for the development of algorithms for the 
generation of MODIS standard and special data products and the approved 
algorithms for generation of MODIS standard data products. 

b. The science team participates in the certification of all standard products 
generated by algorithms used in standard MODIS software. 

c. The science team provides quality assurance criteria for science products. 

d. The science team provides documentation to science users regarding use of the 
instrument and interpretation of instrument data distributed through the DADS. 

e. The science team coordinates science planning for use of the instrument, 
including routine operations and supporting field experiments. 


9 


f. The science team reviews calibrations performed by the MODIS CST. 

g. The science team provides EOS project-approved guidelines, priorities, and 
science plans to the IOT to direct instrument scheduling and commanding. 

h. The science team assists the EOS project in resolving conflicts in scheduling, 
not covered by guidelines provided to the operations team. 

2.3.2 Instrument Operations Team 

The IOT is responsible for ground control of the MODIS instrument and receives 
direction from the MODIS science team. The IOT will normally be resident at the ICC. 
This team has the following roles and responsibilities: 

a. The IOT supports planning and scheduling functions using plans and guidelines 
of the science team and IWGs. 

b. The IOT generates MODIS instrument command sequencing and command files. 

c. The IOT provides routine monitoring of instrument operations (engineering and 
science) and ground-to-space link via DHC. 

d. The IOT performs instrument anomaly detection and preliminary analysis for 
instrument safety. Safe the instrument, when required, per predefined 
procedures. Alert the MODIS science team and CST for anomaly resolution. 

e. The IOT coordinates operations planning, scheduling, and commanding with the 
MODIS science team. 

f. The IOT interacts with and provides necessary support to the EOS mission 
operations team at EMOC. 

g. The IOT supports the MODIS science team and the EOS mission operations 
team at EMOC in coordinating multi-instrument operations. 

2.3.3 MODIS Calibration Support Team 

The MODIS CST is responsible for the characterization and calibration of the MODIS 
instruments. By characterizing the instruments, they ensure the health of MODIS and 
determine proper modes for its continued use. Through calibration, they allow for the 
correct processing of MODIS science data in the generation of higher-level data products. 
This team will include specialists with several different areas of expertise such as 
instrument engineers, physicists, and computer scientists. This document is intended to 
describe only those aspects of the team directly associated with data processing. The 
CST has the following roles and responsibilities: 

a. The CST supports those aspects of calibration, both preflight and inflight, 
which lead to the generation of data products or calibration algorithms. 

b. The CST generates MODIS calibration products ("calibration files") for use by 
the rest of MIDACS and the EOS community. 
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c. The CST develops and maintains standard software for production of MODIS 
Level-1 data. 

d. The CST performs long-term trend analyses on the MODIS instrument. 

e. The CST performs detailed instrument anomaly analyses and formulates appro- 
priate responses. 

f. The CST maintains calibration files and updates Data Quality Assessment (DQA) 
criteria. 

g. The CST provides instrument engineering support to the MODIS science team. 

2.3.4 Product Support Analysts 

Product Support Analysts (PSAs) are responsible for routine product distribution and 
product archiving, ensuring the quality of products and the standard software used to 
generate these products. There may be product support analysts affiliated with the 
science team, the CDHF, the ICC, and the DADS, each having slightly different roles. In 
general, they have the following roles and responsibilities: 

a. The PSAs document the state of all archived products. 

b. The PSAs coordinate the generation and maintenance of directory, catalog, 
inventory, and bibliography for the product archive. 

c. The PSAs ensure the quality of products as they are generated, based on 
quality control criteria defined for them. 

d. The PSAs ensure the quality of ordered products before shipping to the users. 

e. The PSAs provide consultation to science users regarding contents of the 
product archive. 

f. The PSAs ensure the proper archiving of specialized MODIS science products 
received from all EOS investigators. 

g. The PSAs perform maintenance, testing, and configuration control of all 
standard processing software. 

h. The PSAs convert science team-provided algorithms to standard software for 
the production of standard MODIS data products. 

2.3.5 System Operators 

The system operators are responsible for the operation of computer systems (i.e., 
hardware, vendor-supplied software, and applications software) and the generation of 
products in the MIDACS facilities. They are affiliated with each facility, and their roles 
are facility-dependent. In general, they have the following roles and responsibilities: 

a. The Systems Operators operate hardware and software elements in the system. 

b. The Systems Operators monitor the health of hardware and software elements 
in the system. 
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c. The Systems Operators support preventive maintenance of the system. 

d. The Systems Operators perform first-degree diagnostics in the event of system 

(hardware or software) anomaly. 

e. The Systems Operators ensure the security of the computer systems. 

f. The Systems Operators generate MODIS products using defined procedures and 

schedules. 

2.3.6 Science Users 

The MIDACS will serve the science community by responding to MODIS observation 
requests from science users and providing them with science products needed for their 
investigations. These science users, although not MODIS operations personnel, will 
interact with the MIDACS facilities and operations personnel. In general, science users 
are affiliated with universities or research agencies and have no intimate knowledge 
about the MODIS instrument. Although some may be multi-disciplinary, most will work 
in one scientific discipline. 

The following science-users classification scheme may be useful in defining the priority 
of instrument observation requests, resources allocation, privileges and limitations, and 
turnaround time of product generation by the ground system: 

a. MODIS science team members. 

b. NASA-Sponsored EOS Investigators: Includes EOS Interdisciplinary Investiga- 
tors and science team members for instruments other than MODIS. 

c. Other NASA-Sponsored Science Users: Funded by NASA programs other than 
EOS. 

d. NOAA-Sponsored Science Users. 

e. Foreign-Sponsored EOS Investigators. 

f. Other Science Users: Includes non-EOS foreign investigators, researchers of 
other U.S. government agencies (e.g., DoD), and other researchers. 

2.3.7 Data Clerks 

Data clerks will be affiliated with the DADS. They have the following roles and 
responsibilities: 

a. Data clerks perform order desk functions. This includes managing electronic 
orders from the IMC. 

b. Data clerks provide bookkeeping and accounting support to the IMC, to the 
degree necessary. 

c. Data clerks follow-up on the generation of direct data products (e.g., CCTs, 
optical disks, photos), based on product orders. 
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d. Data clerks package and ship direct data products to science users, and report 
these actions to the IMC. 

3. MIDACS OPERATIONS 

The MIDACS is divided into two areas of responsibility: Instrument Operations and Data 
Operations. Instrument operations will be provided by the ICC and the 1ST. Data 
operations will be provided by the CDHF, the TMCF, and the DADS. Figure 3 presents 
the internal MIDACS functional allocation and internal data flows. The internal facilities 
of MIDACS and the respective functions which support the MODIS instrument can be 
summarized as follows. 

Within the ICC, the IOT is responsible for the ground control and monitoring of the 
operation of the MODIS instrument. The IOT will support the instrument planning, 
scheduling, commanding, and status monitoring of the MODIS instrument. 

The 1ST is essentially a workstation connected to the ICC. It gives the team leader 
access to the MODIS control and monitor database in order to support instrument 
integrity functions and to initiate commands and plans for specialized conditions. 

The TMCF will be distributed and will support the development and maintenance of the 
algorithms for the production of calibration and scientific data sets. The TMCF will 
consist of project-provided computing resources at team member locations to be used in 
the development and testing of algorithms, the production of specialized data sets, and 
the assessment of data quality. Because MODIS is a GSFC facility instrument, the 
largest node of the distributed TMCF will be at GSFC and will have a primary responsi- 
bility for all TMCF functions. 

The CDHF has the responsibility of receiving instrument data, and processing and 
generating standard products for the user at predetermined processed levels. 

The DADS will provide for the storage and management of processed MODIS data sets, 
catalogs, and directories for archival data processed by the MIDACS elements. It 
provides an IMC interface to the user for distribution of requested products and 
archiving of data to a permanent archive. 

This section is divided into six subsections which provide detailed discussions of the 
concepts for each functional area. These areas cover: planning and scheduling; control 
and monitoring; data acquisition and production; calibration and validation operations; 
archive, catalog, and distribution; and user access operations. The facilities discussed 
above may, for certain operations concepts, sponsor several functional areas. 

3.1 PLANNING AND SCHEDULING OPERATIONS CONCEPT 

This MIDACS Operations Concept is derived from the information contained in references 
a through d. As an EosDIS unique element, the MIDACS must support the planning and 
scheduling of the MODIS instrument to provide the routine production of scientific 
products derived from its data. The routine production of MODIS data products reflects 
an overall, coordinated scientific plan for the EOS program. The development and 
maintenance of this plan is the responsibility of various working groups whose roles will 
be described below. 
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Figure 3. MIDACS Element Functional Allocation Diagram 



3.1.1 Programmatic Coordination 

The International Coordination Working Group (ICWG) will provide programmatic coordi- 
nation of high-level policy and science consultation and guidance for the international 
EOS mission on all science-related long-range mission objectives. It will consist of one 
to three representatives from each of the major EOS partners. It will recommend 
payload responsibility and platform assignment for EOS, and it may also: establish overall 
objectives, assist in developing scientific requirements, assist in definition of interna- 
tional scientific platform data interfaces, and participate in the EOS project reviews to 
coordinate scientific requirements and mission decisions relating to international scientific 
objectives. It is anticipated that this group will meet infrequently. 

3.1.2 Science Planning Organizations 

3.1. 2.1 International Investigator Working Group (IIWG) 

The organization of the international scientific efforts of EOS is centered around the 
IIWG, formed to coordinate research and operations among the EOS Polar Platforms. 

The IIWG is the primary science element of the international EOS mission and will 
formulate the international observing policy and overall science objectives for all EOS 
platform activities. They will also develop science plans to accommodate special windows 
of opportunity. The IIWG will be divided into four subgroups (IWGs), one for each 
platform. The IIWG will meet once a year during operations to discuss the scientific 
results of the mission and review and coordinate future investigations and related 
observational sequences. 

3. 1.2.2 Investigator Working Group (IWG) 

There will be an IWG for each of the Polar Platforms (two for NASA, one each for ESA 
and Japan). The NASA IWGs are the primary science elements of the NASA EOS Project. 
They play the leading role in the overall optimization of the science return from the two 
U.S. platforms. These activities are coordinated with the IIWG. The NASA IWGs are 
composed of the following members: 

a. EOS Project Scientist (Chairman) 

b. Principal Investigators from that platform 

c. Team Leaders from that platform 

d. Program/Deputy Program Scientist (ex officio) 

The IWG receives policy, guidelines, and overall science objectives from the IIWG. The 
IWG will provide high-level science mission guidance to the EOS Project, establish 
science mission priorities and develop the long term detailed science plan (updated as 
required), and evaluate proposals for data observations submitted to the Science Teams. 
The IWG will meet on a regular basis for exchange of inter-experiment information, 
coordination of investigations, review of requests for specific observational sequences, 
and review of scientific results of the mission. It is the MODIS team leader, a member 
of the IWG, who provides the science plan and coordinated MODIS observation requests 
to the MIDACS for planning and scheduling. 
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3. 1.2. 3 MODIS Science Team 


The MODIS science team consists of selected scientists who are interested in investiga- 
tions which make use of the MODIS Research Facility Instrument being developed by the 
GSFC for the EOS Project. The science team will contribute substantially to guiding its 
design, development, test, calibration, operation, data reduction, and algorithm develop- 
ment. 

The science team will consist of team members and will be organized under the direction 
of a team leader. The science team will plan and conduct investigations, participate in 
final instrument definition, development, test, calibration and operation, and develop 
algorithms for the reduction, analysis, and interpretation of the data, and publish results. 
The science team will have access to the 1ST of the MIDACS from which to participate 
in instrument planning and scheduling, instrument monitoring and problem resolution. 

The science team will also have available the TMCF of the MIDACS to develop and test 
algorithms, analyze MODIS data, and produce special data sets. The science team leader 
and members can access the DADS either directly or through the IMC. Observation 
requests from nonscience team members will be processed through the IMC for authoriza- 
tion by the science team leader. 

3.1.3 MIDACS Instrument Operations 

The MODIS instrument complement of MODIS-T and MODIS-N will routinely acquire 
global or near-global data every day. To accommodate this acquisition, the instrument 
must maintain maximum duty cycles. The data routinely taken by MODIS-N will have a 
100% duty cycle. The data will consist of digital counts from 15 thermal-infrared 
channels at all times and digital counts from 25 reflected-energy channels when scanning 
the illuminated portion of the Earth (approximately 50% of the orbit). MODIS-T will 
routinely take data on a 100% duty cycle during the daytime only. MODIS-T data consist 
of digital counts from 64 reflected-energy channels when scanning the illuminated portion 
of the Earth. MODIS-N will have a simple schedule operation due to its duty cycle and 
constant scan operation, while MODIS-T has an added command operation of tilt forward 
or backward with respect to the orbital velocity while scanning. The routine planning 
and scheduling of MODIS-N and MODIS-T should be dynamic in response to platform and 
communication changes, instrument anomalies, or observation request for TOO, or 
activities unknown at this time. 

In addition to these routine instrument operations to collect science data, instrument 
calibration will also be performed to ensure accurate observations. Calibration of the 
MODIS-N and -T instruments will be maintained throughout the mission lifetime. 
Operation of the instrument to accommodate calibration may impact collection of science 
observation data and routine planning and scheduling procedures. These calibration 
operations include, but are not limited to, instrument operations to determine accuracy of 
radiometric measurements, detector normalization, and long-term stability. Instrument 
operations to monitor calibration sources can be included as part of an observation, or 
may be dependent upon internal or external calibration sources. 

The typical instrument operations concept begins with the science planning process. The 
MODIS science team leader is a member of the IWG and it is through this interface that 
changes to the MODIS Science Plan are conveyed to the MIDACS. The MODIS science 
plan and changes to it are made via the EMOC. Special observation requests or changes 
to the science plan are sent via the 1ST interface by the MODIS team members. A 
special observation request, as opposed to an outright change to the science plan, may be 
just a one-time detector calibration sequence. It is the science team leader’s responsi- 
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bility to coordinate and prioritize changes or additions to the MODIS science plan. The 
resultant information is conveyed to the ICC via the 1ST as an observation request (see 
Section 3.1.4). 

Upon receipt of the observation request, the ICC invokes its planning and scheduling 
apparatus to publish a candidate instrument operational schedule to the EMOC. There, 
the EMOC integrates the MODIS schedule with schedules from all other EOS ICCs. 
Ultimately, a final and approved MODIS schedule is sent back to the ICC, whereupon a 
MODIS command load is released to the EMOC for forwarding to the space segment. 

Once the MODIS commands are implemented, the command verifications are sent to the 
ground via TDRSS either directly or later during a tape recorder playback. It is at this 
time that the ICC/IST Control and Monitor functions of limit checks, caution and alarms, 
command verification, and instrument trending analyses take place. A more detailed 
instrument operations concept is provided in the following subsections. 

A high level diagram, Figure 4, presents the ICC and 1ST elements involved in instrument 
operations. The DHC will receive MODIS engineering data and science data and provide 
it to the ICC for monitoring purposes. The 1ST will provide a conduit for the science 
team leader to request observations and commands, send monitoring algorithms, and to 
receive information about instrument performance and the feasibility of any observation 
request. As a possible alternate path, the CDHF may provide selected science data to 
the ICC for monitoring of the instrument detectors and other science-related instrument 
performance indicators. The ICC will interface with the EMOC for planning and 
scheduling operations and to transmit command loads to the MODIS instrument. 

The 1ST will be used by the MODIS team leader to remotely access the ICC and poten- 
tially to coordinate observation plans with users and science team members. Potential 
functions of the 1ST include providing science planning and coordination and monitoring 
instrument performance. 

3.1.4 Observation Requests 

Science team members and other users will generate observation requests for their 
planned science investigations. The observation request may contain the following 
information: 

Geophvsical/Environmental Information : 

■ Observation Times 

■ Target Location 

■ Cloud Cover Parameters 

■ Surface Types 

Science Information : 

■ Science Objective 

■ Science Products 

■ Monitoring Requests 

Instrument Information : 

■ Spectral Band Selection 

■ Tilt (MODIS-T) 

■ Gain 

■ Calibration 

■ On-Board Processing (reduced resolution) 
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Observation requests may also include information for the scheduling of observation data 
for support of field experiments, possibly at distributed TMCF locations. Field experi- 
ments may require calibrated radiances from 15 MODIS-N and/or -T channels at specific 
target locations, as well as higher-level products, that first must be processed by the 
CDHF in near-real-time (within three to eight hours of the observation). The field 
experiment information will then be incorporated into the baseline observation requests 
for planning and scheduling. 

An observation request may be originated in two ways, either by a science team member 
or a researcher who is not a member of the science team. In the latter case, the 
researcher will enter an observation request through the IMC. The IMC will provide the 
appropriate communication service for transmission of the request to the 1ST for approval 
by the science team leader before notifying the ICC of the request. For a science team 
member-generated observation request, the science team leader will have the responsi- 
bility for transmitting the request via the 1ST to the ICC. In either case, the science 
team leader will have established the guidelines for the submittal of observation requests 
to the ICC and may be involved only by exception or conflict. A standard observation 
request format will be agreed upon for delivery of observation requests. 

3.1.5 Planning and Scheduling Operations 

The IOT will be responsible for MODIS operations, including the equipment and personnel 
necessary for planning and scheduling, of the MODIS instrument. In the context of a 
control center environment, the activities associated with the transformation of a 
requested sequence of space-segment events into an integrated schedule of space (and 
possibly ground) segment events is commonly referred to as planning and scheduling. A 
routine event may enter the planning and scheduling process about a month (see 
scenario) ahead of the event time. This event undergoes the coordination, authorization, 
and approval process. At about one week ahead of event time, the event is typically 
considered scheduled. 

The planning process takes high-level observation requests and generates a candidate 
schedule for instrument operation. This process is completed about one month prior to 
command loading. The scheduling process continues for approximately three weeks and is 
iterated with the EMOC until approval about one week prior to command loading. 

The scheduling process can be divided into three areas of operations: 

a. Initial Schedule Operations 

b. Conflict Resolution 

c. Command Sequence and Mission Plan Generation 

The input of the scheduling process will contain the predicted platform orbit information 
from the EMOC, a set of guidelines for scheduling, and allocated operations envelopes for 
each instrument. Output of the scheduling process will be the initial schedule that is 
sent to the EMOC for approval. Scheduling information will also be sent to the science 
team leader via the 1ST. 

To the extent that the EMOC will provide an operations envelope to the IOT for use in 
scheduling MODIS observations, the IOT will need the capability to model the instrument 
operations at the ICC. It will be the science team leader’s responsibility to convey the 
appropriate modeling parameters. As the performance of the instrument becomes better 
known, the science team leader will provide the IOT, via the 1ST, with changes to any 
monitoring algorithms and instrument models for improved monitoring capabilities. 
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3. 1.5.1 Initial Schedule Operations 

Science planning and coordination involves receiving observation planning information in 
the form of Science Plan objectives from the IWG, special observation requests which 
were derived from external users and MODIS team members, and scheduling displays and 
status reports. This information is all coordinated, prioritized, and integrated into an 
observation request for transmittal to the ICC. 

Figure 5 shows the operations involved in planning and scheduling and introduces the 
concept of a simulator for this purpose. Observation requests are passed through an 
interface to convert the request to a form usable by the ICC simulator. These requests 
are checked against environmental models (orbit, attitude. Sun, and scene) to determine 
the feasibility of the request (such as orbital geometry and observation data for support 
of a field experiment). After passing this check, the instrument utilization for the 
request is modeled to determine the required operations allocation to perform the 
observation. The instrument resource requirements are modeled to the extent that the 
operations envelope is allocated by the EMOC. Possible MODIS resources may be a 
combination of power, thermal, LAN usage, tape recorder usage, instrument tilt and mode 
of operation, and attitude. These resources are dynamic and require constant monitoring 
due to impacts by other instruments (e.g., HIRIS on/off) and platform or TDRSS activity. 

A check of these requirements against the operations envelope is made. If either of 
these checks result in violation of the allocated resources, the IOT will inform the 
science team leader, via the 1ST, of the violation. A candidate schedule request is 
generated if no violations are found and is sent to the EMOC for approval. The candi- 
date schedule consists of optimized instrument sequences, predicted instrument resource 
utilization, predicted instrument performance, and space network scheduling information. 
Updates can be made up to one week before command upload to cover environmental and 
space network changes. All scheduling information is sent to the team leader via the 
1ST. 

3. 1.5.2 Conflict Resolution 

Once a schedule is submitted to EMOC, the EMOC will merge the MODIS schedule 
information with other instrument schedules to identify conflicts in platform resource 
utilization and space network scheduling times. The EMOC will also check the resource 
requirements of the instrument against the operations allocation and guidelines of the 
original planning input to the ICC. Conflicts may be caused by differences in require- 
ments for individual instruments necessary for scientific objectives, operating visible 
channels at night, by conflicts between science goals and system maintenance or com- 
munication schedules, by anomalous behavior of instruments or systems, or by real-time 
requirements. In the case where conflicts exist, the EMOC will send the ICC an iterated 
schedule possibly with changes to the available resources for MODIS. These changes may 
involve rejection of the request or rescheduling TDRSS contacts. In any case, the EMOC 
and/or the IOT will notify the team leader of conflicts to be resolved by the science 
team. After receiving changes by the science team leader, the process of modeling the 
MODIS instrument is again performed and a new schedule request is sent to the EMOC. 
This iteration process will continue until an approved MODIS schedule is resolved. If 
conflicts are not present, the EMOC will send an approved MODIS schedule to the ICC, 
as shown in Figure 5. 
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Figure 5. ICC Planning and Scheduling Operations Concept 




3. 1.5.3 Command Sequence and Mission Plan Generation 

Once a schedule has been resolved through iteration with the EMOC and is approved, the 
IOT will generate a command sequence and mission planning information. The command 
sequence details the command events for a given time period, still in a human readable 
format, for input to the command generation process. These processes are completed 
approximately two weeks before commands are uploaded to the platform. In addition, the 
ICC will generate reference monitoring profiles and mission planning information that will 
be used by the ICC or other ground elements for monitoring instrument performance and 
scheduling data production. The reference monitoring profiles will contain the instrument 
parameter values expected in the downlinked engineering telemetry and will be used as 
input to the ICC’s monitoring function. The mission plan will be used by the CDHF as 
an aid in checking input data and in generating a processing schedule. 

Mission planning information in the form of data requests will also be sent to the DHC 
for scheduling the receipt and transmittal to the CDHF or ICC of real-time or near-real- 
time data for monitoring and field experiment supporting use. 

3.2 CONTROL AND MONITORING OPERATIONS CONCEPT 

The MIDACS, as an EosDIS-unique element, must sustain and maintain the control of the 
MODIS instrument in support of the coordinated science plan. To satisfy these support 
requirements, the IOT at the ICC will provide the control and monitoring functions. 

Control refers to the translation of schedules into command loads required by the MODIS 
instrument and the uplinking of these command loads. Monitoring is the process of 
reviewing MODIS engineering and science data to determine the current MODIS opera- 
tional status. 

3.2.1 Command Load Operations 

Command load operations begin at least two weeks before uploading of commands. Figure 
6 presents the command operations concept of the ICC. The commanding function in the 
ICC will accommodate the automated command sequences described in the previous 
section as well as manually generated commands. The manual command generator will 
accommodate a specific command request from the IOT supervisor or from the team 
leader in the 1ST. It is felt that, up to the command validator, the commands will take 
the form of a functional descriptor (e.g., ALL VIS CH OFF) with comments. The 
command validator will check to see that the input command is an authorized MODIS 
command. From there, the command is sent to the command translator. The command 
translator converts validated commands into a serial bit stream. Headers are appended 
containing information for EMOC, MODIS subsystem addresses, and possibly command load 
verification information. The transmit function will await control authority before being 
forwarded to the EMOC. If the translation of the commands is properly executed, then 
control authority is given and the command load goes out. It is felt that the entire 
process will be automated and that supervisory intervention may only be needed to 
resolve a failed command comparison or to issue a manual command request. 

3.2.1. 1 Emergency Commands 

An emergency command situation may be discovered by the IOT using the ICC monitoring 
function and may be in response to a need to safe the instrument due to anomalous 
platform or instrument conditions, a request by EMOC, or the MODIS science instrument 
team. If the MODIS instrument exceeds its operational envelope, the on-board computer 
of the flight data system may be authorized to independently safe the instrument. It 
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Figure 6. Commanding Operations Concept 
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will then be the responsibility of the IOT and the science team to determine and correct 
the anomalous condition. Most emergency command situations (e.g., instrument safing) 
will have been anticipated and critical command loads pre-generated and uplinked for 
storage on board. They can also be transmitted from the ground during a TDRSS contact 
to facilitate a rapid response. The pre-generation of commands will be an on-going 
process. Note that emergency commands have a double layer of control authority before 
release by the ICC; an authorized safing command load must still await control authority 
before being released. 

3. 2. 1.2 Real-Time Commanding 

Real-time commanding will be done in response to anomalous instrument behavior. A 
string of command loads will be generated and uploaded to the instrument to correct the 
anomaly. Real-time commands will still undergo validation at the ICC and EMOC before 
uploading. 

Note that any command loads released from the ICC commanding function are included in 
the reference monitoring profile for use by the monitoring function for command 
verification. 

3. 2. 1.3 Target of Opportunity (TOO) Commanding 

The TOOs can be thought of as updates to the approved schedule and can be imple- 
mented as an update to a schedule or as a real-time command upload. The IOT will 
respond in an appropriate time line for this type of commanding. Again, the commands 
may be pregenerated to anticipated cases. 

3.2.2 Monitoring Operations 

Figure 7 shows the monitoring operations concept at the ICC. MODIS instrument 
operations will be monitored at the ICC by processing and displaying telemetry data that 
may include combinations of instrument engineering data, science data, and ancillary data 
using multiple downlink interfaces. 

3. 2.2.1 Monitoring of Engineering Data 

The monitoring function includes checks on the calibration, power and thermal loads, 
data generation process, and other engineering parameters required to ensure proper 
operation of the MODIS instrument. The checks will be made as a comparison to the 
reference profile generated in the planning and scheduling or commanding function. 
Cautions and alarms may be generated for display. This process will also detect real- 
time problems and verify proper execution of the command loads sent to the MODIS. If 
an anomaly occurs, commands may be issued in real-time to correct the problem. 

Engineering data will be retained at the ICC for a TBD time to analyze subtle trends or 
problems such as calibration drift, thermal heating, etc. Engineering data will then be 
forwarded to the EMOC and/or DADS for long-term retention. All ICC engineering 
cautions and alarms, command verifications, instrument status, scheduling status and 
trending analyses will be available to the science team leader via the 1ST. The team 
leader (or his delegate) will use these ICC displays, status reports, and database inputs as 
well as science data analysis which is available in the ICC and product monitoring from 
MODIS science team members to thoroughly analyze the MODIS performance. In addition 
to the observation requests discussed earlier, the science team leader may also send 
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Figure 7. Monitoring Operations Concept 
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specific command requests to the ICC for conversion to a command load for uplink at an 
agreed upon time. 

3. 2.2.2 Monitoring of Science Data 

There is a MODIS Level-I Requirement stating that the data system shall monitor 
subsampled science data in near-real-time to assist in the determination of correct 
instrument operation and data return. 

The IOT may also perform analysis of selected science data when required to support 
instrument operations, instrument performance evaluation, and possibly field experiments. 
It is assumed at this time that the MIDACS will receive 100% of the science data directly 
from the DHC in a near-real-time mode of operation. The MIDACS will then sort, 
buffer, select the bands to be monitored in near-real-time, process the selected science 
data to a requested level, and store monitored data for further analysis and display in 
the ICC. Each of the MODIS instruments will be monitored separately on a workstation 
located in the ICC. The monitored science data will be used to evaluate the behavior of 
the instrument in terms of science collection. 

3.3 DATA ACQUISITION AND PROCESSING OPERATIONS CONCEPT 

There is a subtle difference between the terms "acquisition" and "reception." In the case 
of MODIS-N, the 100% duty cycle implies that the instrument data will be received by 
the ground data system without any required active involvement. In the case of HIRIS, 
no data will be taken unless a data acquisition request is generated. MODIS-T offers 
somewhat of a compromise, as the instrument retains a 100% (daytime) duty cycle, but 
takes data at different tilt angles upon request. We use the term "acquisition" here, 
recognizing that it describes a more passive role for the data system than that involved 
with the HIRIS ground data system. 

This section presents a high-level concept of operations for the data acquisition and 
production of MODIS data at the CDHF. The strategy for the routine generation of 
standard Level-1 through Level-4 data products within the MIDACS, and specifically the 
CDHF, is driven by a number of functional and performance requirements. The sources 
of these requirements and related constraints include the MODIS/HIRIS Level-I Require- 
ments Document, the MIDACS Functional Requirements Document, the MIDACS Levels-1 
through -4 Processing Operations Concept, and other EosDIS and scientific documenta- 
tion. 

A context diagram showing the CDHF interfaces with other EosDIS elements is given in 
Figure 8. The primary input to the CDHF is Level-0 and ancillary data received from 
the DHC. The processing within the CDHF can be broken into three separate subfunc- 
tions: receive data, manage processing, and produce MODIS data products. 

Here we consider the generation of standard MODIS data products within the CDHF as a 
part of EosDIS. The MODIS CDHF is responsible for: 

a. Simultaneously generating MODIS standard products at Levels-IA, -IB, -2, -3, 
and -4. 

b. Supporting field experiments and the observation of targets of opportunity 
through the generation of near-real-time products. 

c. Reprocessing standard products at a rate of at least twice the original rate. 
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Figure 8. The CDHF Context Diagram 



d. Supporting (in some not yet fully determined manner) algorithm developmental 
activities in their final stages prior to integration, perhaps in the form of 
special processing requests. 

The CDHF will, as a part of its processing of 1, 2, and 3 above, routinely generate the 
corresponding browse data and metadata. The requirements constraining these activities 
(and others, such as routine maintenance) will be met jointly and, in doing so, it is not 
expected that the resources in the CDHF will be utilized beyond a level of 50% to 70%. 

3.3.1 Receive Data 

The receive data function accounts for data packets received from the DHC and gener- 
ates received data ledger information that is compared to data timelines derived from 
mission planning information from the ICC. Missing data are requested to be retrans- 
mitted, and data are catalogued, stored, and made available for further processing. 

3.3.1. 1 Priority Data Types 

Two types of priority data are available from the DHC. During the time when direct 
TDRSS contact is maintained, engineering data may be sent from the platform to the 
ground in real-time without the necessity of first recording the data on the onboard tape 
recorder. These data may be given priority handling at each of the CDOS ground 
processing nodes (DIF and DHC), so that these data are available essentially in real-time 
at the output of the DHC. The other type of priority data supported by the CDOS is 
priority playback. In this mode, the recorded data are given priority handling identical 
to that given real-time data once the data are retrieved from the onboard recorder. 
Essentially, these data have been delayed only by the time that elapsed between the 
recording and playback of the data. 

The near-real-time processing in the CDHF can be applied to either of these CDOS data 
types. The switch to the near real-time mode occurs under the control of the manage 
processing function and may be applied to any of the processing capabilities supported by 
the produce MODIS data products function. The method that the CDOS will use to 
recognize priority data has not yet been defined. Presumably, near real-time processing 
in the CDHF can be initiated by the same control mechanism used to initiate priority 
handling within the CDOS. Except for possible missing data segments or "holes" in the 
received data, data that are received under priority handling are identical to that 
received using routine handling procedures. Since a request for retransmission of data 
would of necessity involve a delay while tapes are repositioned to obtain the required 
data, the priority handling mode does not necessarily support retransmission requests. 
Systems receiving priority data are each individually responsible for providing appropriate 
system responses to missing data segments. Except for effects resulting from missing 
data segments, the CDHF products generated in the near real-time mode are identical to 
those generated in routine processing. 

3.3.2 Manage Processing and Handle Data 

The manage processing function consists of data management and processing control 
functions needed to produce MODIS data products. Processing requests, new or modified 
processing algorithms, or modified DQA criteria are received from the TMCF and 
implemented through this function. If previously processed data products must be 
retrieved for use as inputs to higher-level processing, data requests are generated, and 
requested data is received, and managed. MODIS data products and archive ancillary 
data are sent to the DADS. DQA reports and selected data products are sent to the 
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TMCF, and production status reports are forwarded to the IMC. The manage processing 
function will be extended in some length in Section 3.3.3.4, Processing Strategy. 

3.3.3 Produce MODIS Data Products 

The generation of Level-1 through -4 data products, near-real-time data products, and 
browse data products are accomplished under the produce MODIS data products subfunc- 
tion. 


3.3.3. 1 Level-1 Processing Operations Concept 

MODIS Level-1 data processing takes place in the CDHF and involves the transformation 
of Level-0 data received from the DHC into Level-IA and -IB data products. The 
Level-1 processing operations concept presented below is based upon the Level-1 data 
product requirements. This concept consists of a description of the steps involved in 
Level-IA and -IB processing. 

There may be two Level-1 MODIS standard products: Level-IA and Level-IB. The 1A 
product will, by definition, be reversible to Level-0. As such, no science or ancillary 
information will have been lost in its generation. The primary uses of 1A data will be: 

(1) to expedite the processing of higher-level MODIS data and (2) as an archive resource 
to permit possible future reprocessing of MODIS data. The 1A data will also be used by 
the CST for the maintenance of the MODIS calibrations. The Level-IB product will be 
derived solely from the Level-IA data and will no longer be reversible to Level-0. Most 
of the instrument and platform ancillary data will not be required at higher levels of 
processing, and thus probably will not be retained at Level-IB, providing this product 
level is required (although the ancillary data volume will be small compared to that of 
the sensor data). The ancillary data that is retained will be irreversibly transformed: 
platform attitude and ephemeris and instrument pointing information into observation 
vectors and footprint locations; observation vectors and solar ephemeris into satellite and 
solar zenith angles and relative azimuth. Some or all of the instrument data will be 
irreversibly transformed through the application of nonlinear calibrations. Once used, the 
detector voltages and instrument temperatures will have no higher-level application. 

There may be multiple levels of 1A data, particularly if IB data is not required (due to a 
proven reversibility to Level-0 of the calibrated MODIS data), nly the highest level of 
1A data will be archived as the MODIS Level-IA standard product. 

The production of a Level-IA data record will require the assemblage of many packets of 
Level-0 data. These packets will have been delivered by the DHC and will be: 

a. Error corrected to a bit error rate of better than 10* 8 . (At 10' 12 , on average 
only one bad MODIS bit will be encountered every day. However, at a bit 
error rate of only 10' 8 , 10,000 bad bits will be encountered daily.) The 
packets with uncorrectable errors will be flagged as such by the DHC. The 
MODIS science team will require a bit error rate of no worse than 10‘ 8 (and 
may arguably require a bit error rate of no worse than 10' 10 ). 

b. Arranged in chronological order, with duplicate packets deleted, and without 
any gaps in coverage to no less than the 99.9% level. (Because MODIS data 
will be used to produce products with global coverage, missing packets will 
degrade the quality of the final product. Completeness to only the 99% level 
would result in a loss of 15 minutes of coverage; at 6.5 km per second, this is 
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a 51°, or about a 5600 km, swath along the orbit.) The MODIS science team 
will require coverage to no less than 99.9%. 

c. Composed of the set of all MODIS science and ancillary data packets and all 
platform and other ancillary data packets required for processing. 

The Level-IA records will be created by collecting information from the various input 
data packets, unpacking the data from the packets, and organizing them into the physical 
records. Other information, not derived directly from the Level-0 data, will be required. 
This data will include calibration coefficients and algorithm/processing history informa- 
tion. 

The production of a Level-IB data record will require only the Level-IA data as input. 

As such, it may be computationally efficient to produce the IB data record immediately 
upon completion of the 1A record, while the 1A data is still in memory. (Note that this 
strategy would preclude intervention by the CST for purposes of altering the calibration 
in near-real-time. As conceived, the IB data will actually be composed of four types of 
information: identification data, ancillary data, georeference data, and radiance data. 
(Because the georeference data and probably each of the first three data types will be 
useful to users of the Level-2 data products as well, it may be useful to put the 
information into a common data base shared by the Level-IB and -2 products within the 
MIDACS and later in long-term archive. As such, the MODIS standard product would 
actually be "distributed" with cross-referenced elements residing in two separate loca- 
tions. In the process of filling a Level-IB or -2 order by a MODIS data user, the DADS 
would generate a file structure similar to that in Tables 1 and 2 by combining informa- 
tion from the Level-IB, -2, or georeference data sources.) 

There are four basic processing steps required to produce a Level-IA product from the 
Level-0 data. The first is the reorganization and unpacking of the sensor data into a 
structure that expedites efficient application of algorithms in the higher level of 
processing. The second processing step is to append georeferencing information, and 
calibration parameters or tables. In the third, header record information is generated to 
facilitate cataloging and data extraction. Finally, after the higher levels of processing 
are completed, the data may be compressed in order to minimize the volume of the 
Level-IA data set. Each of the first three processing steps is discussed below. 

3.3.3.1.1 Reorganization of Data. At the higher levels of processing, the need to remap 
and resample data implies that the sensor data be arranged in channel-sequential order 
(i.e., with sequential pixels in a scan line from the same channel). For purposes of 
forming images, the optimum data record structure should be based upon the scan of the 
instrument. A natural organization of the data would be to define the logical data 
record as the amount of data observed in one scan of the instrument arranged as 
complete swaths, one for each spectral channel. The resulting logical data record 
volumes would be quite large and smaller computing systems might have trouble ingesting 
and operating on such large logical data records. 

It is conceivable that a hierarchy of logical data records could be created within the 
Level-IA and -IB products so that the large volume logical data record could be received 
by large capacity processors such as those of the CDHF. Smaller logical data record 
lengths could be input into mini- and micro-computers for processing and analysis. Such 
a hierarchy might be defined so that the largest logical data record would be one 
complete scan as mentioned above. Smaller data record structures could then be defined 
as segments of a scan. 


30 


The Level-IA processing software will reorder the Level-0 data to that of channel 
sequential pixels for each scan. Limit checking will also be performed at this step in 
the processing. The degree of segmentation that will form the smaller logical data 
records is TBD. 

The processing software must be capable of processing MODIS observations as they are 
received, i.e., on an observation-by-observation basis. Conventionally, however, it is 
common to accumulate some amount of data before processing is begun (perhaps up to 
one orbit of data, or one day of data for a lower-rate instrument). If the MODIS sensor 
data is spectrally/chronologically reordered as a part of the Level-IA processing, then 
the smallest convenient parcel of data for processing is one complete scan. For 
MODIS-N, with eight 1 km resolution detectors along track, this is just over one second 
of data. For MODIS-T, with 64 1 km resolution detectors along track, this corresponds 
to about 10 seconds of data. If spatial resampling along the scan is performed as a part 
of the Level-IB processing, then the smallest convenient parcel of data for processing is 
a complete scan line from one detector, or about 1/6 second of data. 

3.3. 3.1. 2 Appended Data. Raw georeferencing and time information, including spacecraft 
ephemeris, spacecraft attitude, instrument pointing (MODIS-T), time code, and GPS time 
correction will be appended to the Level-IA data with the minimum processing required 
for spatial and temporal cataloging of the Level-IA data. This will require conversion of 
the platform time code into universal time to give the start and stop times at least at 

the level of the largest logical data record. Similarly, Earth location calculations may be 
performed at Level-IA for portions of each largest logical data record (e.g., the locations 
of a corner of each swath could be calculated). This information will then be appended 
to provide general information regarding start and stop times and geographic coverage to 
users of Level-IA data. 

Within each data record, the sensor data is sorted by channel, and by detector scan line 
within each spectral channel of data. For the case of MODIS-T, this will create a 
physical record approximately ten megabytes in length. The first three logical records 
will contain the identification, ancillary, and georeference data. The remaining 64 logical 
records will each contain the radiance for a single spectral channel. This structure 
facilitates the spectral subsetting of the Level-IB product within the DADS to meet 
specific data requests. 

Appended to each swath of data, in the form of raw counts, will be the sensor calibra- 
tion observations, calibration target temperatures, lamp currents, etc., and other ancillary 
data, such as instrument housing temperatures, relevant to radiometric calibration. No 
further processing of these data will occur at this point. 

3.3.3.1.3 Header Information/ Data Compression. All of the information necessary for 
cataloging and data extraction will be computed and inserted in the headers. (See the 
Level-1 Data Products Requirements.) A lossless data compression algorithm may be 
applied to the data to reduce the volume of data that must be archived. 
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3 . 3 . 3.2 Level-IB Processing Steps 

To the extent possible, the Level-IA data structure will be preserved in the Level-IB 
products. The basic Level-IB processing steps described below are: Earth location, 
satellite/solar zenith angle/relative azimuth angle determination, and time calculations; 
radiometric calibration; data quality assessment; header record processing; and repacking. 

3 . 3 . 3 . 2.1 Earth Location. Earth latitude, longitude, solar and instrument zenith angles 
will be calculated using the attitude and ephemeris data on the Level-IA product. These 
calculations may be performed only at selected anchor points to produce a sparse lattice 
of points which cover each swath of observations in order to reduce the computation 
requirement. The Earth locations and zenith angles of all other pixels in the swath will 
be determined by interpolation between the anchor points during Level-2 processing. 

Initial analyses, yet to be confirmed, indicate that it may be possible to perform the 
direct calculations for about 10 pixels in only one out of every 50 or 100 scan lines and 
still achieve the desired level of accuracy. 

3 . 3 . 3 . 2.2 Radiometric Calibrations. The basic method used to radiometrically calibrate 
the raw detector output data involves the application of a calibration equation with 
coefficients such as the detector gains derived from the periodically scheduled calibration 
observations. This process yields a new pixel value that represents the physical value, 
i.e., radiance or intensity, observed by the instrument. The coefficients in this equation 
are determined by commanding the instrument to look at internal calibration targets of 
known intensity or regions on the Earth’s surface with known properties. 

A calibration equation will be required for every spectral channel for each scan line and 
detector. Thus, for MODIS-N, 8 x (30 x 1 + 8 x 4 + 2 x 16) = 752 equations will be 
required, and 64 x 64 = 4096 equations will be required for MODIS-T. These equations 
must be applied to every pixel of observed data. The sun, through a diffuser plate or 
integrating sphere, will likely be the principal calibration source for the visible and near- 
infrared channels. The calibration observations for these channels will be made (at most) 
once per orbit as the spacecraft passes the terminator. On the other hand, the thermal 
and infrared channel calibration observations will use an internal calibration target which 
can be viewed during each scan cycle of the instrument, except in a stare mode. Both 
types of channels will make use of periodic space looks, which could be performed as 
often as once each scan. The calibration constants will be determined by using appro- 
priate averages or samples of these calibration observations. 

The data processing steps for radiometric calibration consist of selecting the samples 
from the calibration observation data that provide a full solar or thermal target view, 
performing noise screening to reject noisy observations, and applying the calibration 
equation to every pixel in one or more swaths of data. Target observations must be 
converted into values of intensity that are, to the highest accuracy possible, traceable to 
known intensity standards. In the case of the solar calibration observations, seasonal 
trends in observed solar intensity, due to azimuth angle changes and changes in the 
distance to the sun, must be removed to provide normalized calibration intensities. The 
thermal calibration targets are monitored by a number of temperature sensors. Here, 
data processing must be performed to convert the temperature sensor voltages into a 
calibration target temperature which permits the calculation of the calibration radiance. 

The calibration process will be monitored by members of the MODIS CST who will 
examine long term trends, instrument response, calibration target characteristics, etc. 

This may result in improved calibration algorithms or modifications to the calibration 
constants to remove trends in instrument response and or calibration target output. 
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Implementation of these new algorithms (and possibly the constants) will necessitate 
delaying the Level-IB production process, or require reprocessing of the Level-IB data. 

3.3.3.2.3 Data Quality Assessment. Part of the Level- IB processing will include overall 
data quality control, and the resulting statistics will be appended to the Level- IB data. 

All of the information necessary to access and retrieve the data will be placed in the 
header records (See the Level-1 Data Product Requirements). 

3.3. 3.2. 4 Record Processing /Compression. Reprocessing of Level- 1 may necessitate 
reprocessing of all higher level products. Reprocessing of Level-IA data is not antici- 
pated and would only be necessary if improved values of the basic telemetered informa- 
tion from the instrument or spacecraft are provided. The reprocessing would consist of 
replacing the values in the current version of Level-IA with the improved counts and 
updating the header information. Reprocessing of Level-IB data may be required if and 
when new calibration algorithms and/or calibration constants are identified by the science 
team. New intensity or radiance values will be calculated, and the header data and 
documentation will be updated. A lossless data compression algorithm may be applied to 
the data to reduce the volume of data that must be archived. 

3. 3.3. 3 Level-2, -3, and -4 Processing Operations Concept 

The CDHF sequentially derives Level-2, -3, and -4 products from the appropriate lower- 
level data and ancillary data. The Level-2, -3, -4 processors will be capable of per- 
forming reprocessing, /special request processing, near-real-time processing, and routine 
processing. All MODIS data received will be processed to Level-2 within 72 hours of 
observation and to Level-3 within 96 hours of observation. The processing operations 
concept presented here stems from the Level-2, -3, -4 Data Product Requirements and 
consists of a description of what happens at each processing level. 

3.3.3. 3.1 Level-2 Processing. The Level-2 Processor receives Level- IB data and any 
necessary ancillary data. This ancillary data could include, for example, Level-IB (or 
Level-2) data from other instruments, either in space or ground-based. Level-2 process- 
ing derives geophysical parameters from these inputs by the application of the geophys- 
ical parameter algorithms. In data structure, the Level-2 products will be similar to the 
Level-IB product, that is, it will consist of orbital swaths of geophysical parameter data 
along with appended information. 

While the Level-IA and -IB products contain all the MODIS instrument data at that 
processing level, at Level-2 there will exist many standard products. Each product may 
contain one or more related parameters. The different Level-2 products will be produced 
from the same Level-IB data. These Level-2 products will apply: 

a. Globally, as with estimates of cloudiness and radiation budget components. 

b. To specific surface types, such as sea-surface temperature or phytoplankton 
over the oceans only, vegetative index and soil moisture over land only. 

c. Regionally, such as snow/ice bidirectional models over the polar regions, 
precipitation and irrotational flow estimates over the tropics, and specific 
interests for only certain areas of the Earth. 

From I/O considerations, it may be computationally efficient to generate all Level-2 
products "at the same time." Here we do not mean processing the different parameters 
simultaneously, but instead creating physical records for all Level-2 products from the 
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same IB record before processing the next IB record. As noted in the previous section, 
the Level-2 products might share common georeference information. It is anticipated 
that this mode of processing will be possible for many or most of the Level-2 algorithms. 
However, certain Level-2 products will require additional information: 

a. Collocated looks by MODIS-T at the same region from two or more different 
tilts (from within the same orbit). 

b. Collocated views by both MODIS-N and MODIS-T of the same region. 

c. Simultaneous data from other instruments on board the same polar platform. 

d. Collocated data from instruments on board other platforms or systems, 
including conventional (ground, balloon, ship, or aircraft) data. 

In some or all of these possible situations, the generation of the specific Level-2 product 
would have to occur independently, perhaps after processing of all Level-IB and the 
simpler Level-2 products was completed for the day of data. As additional standard 
Level-2 products are approved for generation, production of the parameters will com- 
mence on the day the algorithms are integrated. The processing of data computed from 
these new algorithms for the period prior to integration will be treated as with repro- 
cessing: handled separately from the routine data stream and at least twice the real-time 
data rate. 

3. 3.3. 3.2 Level-3 Processing. Using any necessary ancillary data, the Level-3 processor 
maps Levels-1 and -2 data onto an Earth-fixed grid associated with a desired map 
projection. This process includes temporal and/or spatial and temporal resolution of the 
Level-3 data. Standard grids are anticipated with multiple resolutions in space and time, 
with domains ranging from regional (e.g., polar) to global. 

3. 3.3. 3.3 Level-4 Processing. As presently conceived, Level-4 products consist of model 
output and scientific validation analyses of lower data. Model input would be Levels-1, 
-2, or -3 data and could include ancillary data and/or correlative data. For example, one 
might compute the ocean surface carbon flux from MODIS-derived chlorophyll measure- 
ments combined with other sea surface parameters, or use radiosonde profiles and 
radiative transfer models to generate spectral radiances for comparison to the Level-IB 
measurements. A validation analysis product could be a map of the differences between 
the data of a scatter plot of a retrieved parameter versus coincident ground truth data. 
All levels of processing will include a data quality assessment which will be appended to 
the data product. Any information needed to access and retrieve the data product will 
appear in the header appended to the data. In addition, each of the products will 
include the following appended information describing how the product was produced: 
product version number, appended information from the lower level input data, geophys- 
ical parameter identification, geophysical parameter algorithm version identification, 
gridding description and statistics for Level-3, correlative data information, and geophys- 
ical or applications model identification for Level-4. 

Level-4 processing has the potential to become even more intensive than Level-2 
processing. This is because of the large amount of data that may be produced and also 
the potentially large number of processing instructions needed to do the complicated 
calculations. 
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3. 3.3.4 


Browse Data Processing 


Browse data sets will be produced by time, space, and/or spectral averaging or sampling 
of the associated standard product. This results in a relatively low volume data set 
which can be readily transmitted electronically to be viewed rapidly by a remote user. 

Browse data products will be delivered to the DADS with the same timeliness as that for 
the associated standard product. Browse production is considered to be a part of 
standard/routine processing. A subset of browse data may be delivered to the IMC. 

Two types of browse data have been defined: (a) 20 kilometer resolution, single-byte 
latitude/longitude scenes, with four spectral channels each for MODIS-N and -T as well 
as for each of their Level-2 parameters, eight of these scenes cover the Earth, and an 
additional eight of which are defined for specific domains of general interest (e.g., 
Antarctica, tropical Pacific Ocean); (b) four kilometer resolution single-byte cross- 
track/along-track scenes, with two spectral channels each for MODIS-N and -T, twenty 
of these scenes cover each orbit (ten during daylight only for MODIS-T). This data will 
require storage equivalent to less than 0.5% of the full resolution MODIS data. 

3.3.3.5 Other Processing Modes 

In addition to routine processing, there are the following processing modes: reprocess- 
ing, special request processing, and near real-time processing. 

3.3. 3.5.1 Reprocessing. The science team may request that Levels- 1 through -4 data be 
reprocessed and would supply updated calibration algorithms and/or science algorithms. 
Reprocessing will occur without interruption of routine production activities and at least 
twice the routine processing rate. By reprocessing we mean either: 

a. Updating and replacing products with data produced with improved algorithms 
or calibration. 

b. Retrospective processing, once a new product is introduced, to increase the 
temporal coverage of the estimates time series. 

3.3. 3.5.2 Special Request Processing. The science team will occasionally request that a 
particular algorithm be tested on the CDHF before it is implemented in the routine 
processing procedure. 

3.3.3.5.3 Near-Real-Time Processing. The near real-time processing mode is used to 
provide immediate access to CDHF processing for data items that are needed in less than 
the usual processing turn around times. As an example, the science team may require 
some Levels-1 and -2 data in time to support a field experiment. The appropriate 
portions of Level-0 data would be mandated and processed as priority data at the DHC 
and similarly processed on a priority basis at the CDHF without disruption of routine 
processing. The resulting near real-time products would be delivered to the requestor 
within three to eight hours of observation. 

3.3.3.5.4 Processing Strategy. Driving the data acquisition and processing operations 
concept are the following requirements and guidelines: 

a. MIDACS shall force no delays in the processing operation which preclude the 
direct flow of acquired data through the system. 
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b. The routine delivery of Level-0 data to MIDACS will be guaranteed no later 
than 24 hours after the observation. 

c. The combined sampling rate for the MODIS-N and MODIS-T instruments will 
be on the order of 10 6 radiance measurements per second and 10 11 measure- 
ments per day. 

d. All MODIS observations will be processed to yield standard data products to 
Levels- 1 A, -IB, -2, and -3 by MIDACS. 

e. MIDACS will process and make available data through Level-1 B within 48 hours 
of observation; through Level-2 within 72 hours of observation; and through 
Level-3 within 96 hours of observation. 

f. On the order of 100 standard level-2 products will be generated by MIDACS. 

g. Browse data and metadata associated with the standard products will be 
delivered to archive with the same timeliness as the products themselves. 

h. MODIS sensor data will be sequentially ordered by buffering and processing, 
either on board the platform or in the Level-1 A processing, by scan line and 
then channel. 

Taken literally, the first requirement clearly states that the processing software must be 
capable of processing MODIS observations as they are received, i.e., on an observation- 
by-observation basis. Conventionally, however, it is common to accumulate some amount 
of data before processing is begun (perhaps up to one orbit of data, or one day of data 
for a lower-rate instrument). If the MODIS sensor data is spectrally/chronologically 
reordered as a part of the Level-IA processing, then the smallest convenient parcel of 
data for processing is one complete scan. For MODIS-N, with eight 1-km resolution 
detectors along track, this is just over one second of data. For MODIS-T, with 64 1-km 
resolution detectors along track, this corresponds to about 10 seconds of data. For most 
Level-2 applications, multiple collocated spectral bands of radiances will be required to 
generate geophysical parameters. In some conceivable Level-2 applications, collocated 
observations from the same spectral channel will be needed, but from different points 
along the orbit (with varying zenith/azimuth angles). At Level-3, multiple orbits of data 
will be needed to perform spatial averaging and mosaicking. 

It seems reasonable to process the MODIS data in segments, thus forcing some delay in 
the processing of the earliest observations of the time period covered by the segment. 

The exact length of the processing segment must await the results of a trade-off study 
considering both I/O and RAM storage factors, but will be in the range of from one scan 
to one orbit of data (and may be a variable). In either case, the processing system can 
track the data granule through a unique label (scan number and orbit number). On the 
order of 10 5 and 10 4 segments of MODIS-N and MODIS-T data, respectively, would be 
acquired daily. Once a segment of data is processed from Level-0 to Level-1 A, it can 
then be processed to Level-IB, and then to Level-2, without waiting for additional 
segments to be processed. Incidentally, this procedure may facilitate the processing of 
subsets of the MODIS data in near-real-time without the need for duplication of effort. 

Within each record, the sensor data is sorted by channel and by detector scan line 
within each spectral channel of data (Tables 1 and 2). For the case of MODIS-T, this 
will create a physical record approximately ten megabytes in length. The first three 
logical records will contain the identification, ancillary, and georeference (latitude. 
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longitude, solar and satellite zenith angles, and relative azimuth) data. The remaining 64 
logical records will each contain the radiance for a single spectral channel. This struc- 
ture facilitates the spectral subsetting of the Level-IB product within the DADS to meet 
specific data requests. 

Level-2 standard products can be organized in precisely the same manner, simply by 
substituting geophysical products for the calibrated radiances. However, there are many 
arguments for not putting all Level-2 parameters on the same physical record or data set. 
In particular: (1) the terrestrial, oceanic, and atmospheric data will ultimately reside in 
different long-term archives; (2) there will rarely be a simultaneous need for more than a 
subset of Level-2 parameters; and (3) reprocessing at Level-2 will generally occur 
individually for each product, and not globally as might be the case for Level-1 B. Level- 
IB contains 64 (40) channels and Level-2 may have just a few parameters on the same 
product. (There may be many Level-2 products.) This opens the question as to whether 
it will be necessary to produce and archive repetitive information for each product. It 
may be sufficient to have a standard Level-2 georeference product, which is accessed by 
the DADS in the process of filling orders at the same time as the requested products. 

It is clear that the data rates and volumes, coupled with the short delivery periods 
required for the standard products, require that any CDHF data processing strategy be 
developed well in advance of the application. Only by specifying this methodology early 
(to the level of the product, physical record, logical record, and algorithm) will the 
processing throughput be optimized and the most cost-effective data system created. 

The production of MODIS products is, by definition, hierarchical: lower-level products are 
required as input into algorithms designed to generate higher-level products. There can 
be no Level-1 product without Level-0 data, and no Level-2 products without Level-IB 
data. However, the product levels need not always be produced in sequence: Level-3 
products may be generated from either Level-IB or Level-2 data, and Level-4 products 
may be generated from either Level-2 or Level-3 data (or perhaps both). Many Level-2 
products will be produced from subsets of the same Level-IB data, sometimes in concert 
with information from non-MODIS data sources. 

Processing the MODIS data in segments (such as complete instrument scans) permits the 
data to be handled in terms of records. Some 1,000 to 10,000 of these segments of data 
will have to be processed through all data levels on a daily basis for MODIS-N and 
MODIS-T. There will be up to 100 Level-2 products generated by MIDACS. Each 
product will consist of one or more parameters and will have either global or regional 
coverage. As a result, on the order of 10 6 separate processing steps will be required to 
get through Level-2. This processing will occur on a daily basis, 7 days a week, 52 
weeks a year. A high degree of automation will expedite the operation of this facility. 

It is possible that an expert system will be required to optimally control the data 
processing operation. The software would need to consider each of the guidelines and 
constraints a human operator would use: availability of the input information, 
memory/IO/CPU efficiency, memory/online storage management, timeliness requirements, 
conflicting demands for resources for reprocessing and other applications, scheduled 
maintenance, etc. 
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Table 1 

Level-1 MODIS-T Product Physical Record Structure 


Instrument ID 
8 Byte 

Orbit Number/Scan Number 
16 Bytes 

Data History (Input Data History/Algorithm Version/Calibration Version/Processing Date) 

4.000 Bytes (Recommend ASCII) 

Instrument Ancillary Data (e.g.. Instrument Tilt/Operating Mode) 

2.000 Bytes 

Platform Ancillary Data (e.g., Observation Time) 

2,000 Bytes 

Data Quality Information 

64 Channels * 64 Scan Lines / 8 Bits = 512 Bytes 

Anchor Point Earth Locations/Earth-Sun-Satellite Geometry 

20 Bytes * 64 Scan Lines * 1,294 Pixels / 4 Pixels per Anchor Point / 4 Scan Lines 
per Anchor Point = 103,520 Bytes 


Calibrated Radiances 

64 Channels * 64 Scan Lines * 1,294 Pixels * 2 Bytes = 10,600,448 Bytes 


Identification Logical Record: 4,024 Bytes 

Ancillary Data Logical Record: 4,512 Bytes 

Georeference Logical Record: 103,520 Bytes 

Channel 1 Radiance Logical Record: 165,632 Bytes 
Channel 2 Radiance Logical Record: 165,632 Bytes 
Channel64 Radiance Logical Record: 165,632 Bytes 


Total Physical Record Length 10,712,504 Bytes 

Number of Physical Records per Orbit: 313 (Day Only) 

Number of Orbits per Day: 14 
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Table 2 

Level- 1 MODIS-N Product Physical Record Structure 


Instrument ID 
8 Byte 

Orbit Number/Scan Number 
16 Bytes 

Data History (Input Data History/Algorithm Version/Calibration Version/Processing Date) 

4.000 Bytes (Recommend ASCII) 

Instrument Ancillary Data (Mode of Operation) 

2.000 Bytes 

Platform Ancillary Data (e.g.. Observation Time) 

2,000 Bytes 

Data Quality Information 

94 Detectors per Kilometer * 8 Kilometers / 8 Bits = 94 Bytes 


Anchor Point Earth Locations/Earth-Sun-Satellite Geometry 

20 Bytes * 8 Scan Lines * 1,294 Pixels / 4 Pixels per Anchor Point / 4 Scan Lines 
per Anchor Point = 12,940 Bytes 


Calibrated Radiances 

94 Detectors* 8 Scan Lines * 1,294 Pixels * 2 Bytes = 1,946,176 Bytes 


Identification Logical Record: 4,024 Bytes 

Ancillary Data Logical Record: 4,512 Bytes 

Georeference Logical Record: 12,940 Bytes 

Radiance Logical Record (1 km res): 20,704 Bytes 
30 channels during day 
15 channels during night 

Radiance Logical Record (500 m res): 20,704 Bytes 
8 channels during day 
0 channels during night 

Radiance Logical Record (250 m res): 20,704 Bytes 
2 channels during day 
0 channels during night 


Total Physical Record Length 10,607,674 Bytes 

Number of Physical Records per Orbit: 626 

313 (Day Only) 

313 (Night Only) 

Number of Orbits per Day: 14 
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After standard data products are created, yet before they are placed into archive, 
additional processing is required: 

a. The data must be certified. As anticipated, algorithms will be supplied to the 
CDHF by the MODIS science team along with certification criteria. Data 
passing these quality assurance criteria will be considered certified and will be 
delivered to the DADS for archival. Data failing these quality assurance tests 
will be delivered to the DADS as noncertified data. The science team will be 
notified that the certification criteria are not being met. 

b. The browse data must be created. Browse data will be single-byte spectral and 
spatial summaries/subsets of the full resolution MODIS products. 

c. The catalog information must be compiled. This data will contain information 
regarding the complete histories of the product and its parent data sets, 
including the algorithms used, DQA statistics, and any other relevant informa- 
tion. 

d. The metadata must be generated. The metadata is a summary of the charac- 
teristics of the data product which may be broken down in terms of each 
processing segment. Metadata will be specifically directed towards assisting 
the MODIS data user in selecting and manipulating MODIS data. 

This additional data must be produced within the CDHF prior to delivery at the DADS. 

It is possible that the DQA, browse, and metadata can be produced on a record-by-record 
basis, while the catalog information (equivalent to header and trailer records on a MODIS 
product file or volume) must await the completion of processing for the product (e.g., 
one day of data in the case of Levels 1-2). 

3.4 CALIBRATION AND VALIDATION OPERATIONS CONCEPT 

As shown in the context diagram in Figure 9, the TMCF is distributed and is composed 
of project-provided computing facilities used to develop scientific and calibration 
algorithms, verify and validate data, and to generate some specialized data sets at team 
members sites. As an organizational unit, the TMCF is where the science team leader 
provides planning and coordination for the MODIS science team members and for 
MIDACS. The TMCF is a distributed network of workstations at science team member 
locations and (perhaps) temporarily at the site of a field experiment. The network node 
at GSFC is where several science team members including the science team leader are 
expected to reside along with the CST. A group of computer scientists engaged in 
making the algorithms developed by the science team members more efficient and in 
developing software which would have general utility to all team members may also reside 
at the GSFC facility. The GSFC TMCF node is central to the TMCF network and will 
probably have the greatest amount of project-provided computing facilities. 

The CST is a resource within the GSFC TMCF node of MIDACS for the activities 
associated with the data processing and algorithm development required for calibration. 
The CST will have more activities than are described here (we concentrate on the data 
processing aspects of calibration). This team is composed of science team members, 
instrument engineers, and supporting staff. Its primary responsibilities will be to see 
that the ground calibrations are properly performed and to provide continuity in the 
calibration between the pre-launch and in-flight periods. After launch, primary responsi- 
bility of the CST will be to provide calibration coefficients and algorithms to the CDHF 
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so that Level-IB data can be generated. The MODIS Calibration Data Products Plan 
provides more information on the CST activities. 

In addition to communications which may be required between the TMCF’s, each TMCF 
will require communications with: 1) the Central Data Handling Facility (CDHF), 2) the 
Data Archive and Distribution System (DADS), 3) the Information Managg*ent Center 
(IMC), and 4) non-EOS data sources. 

Communications will consist of textual messages (as with the 1ST), interactive database 
inquiries (as with the IMC), and the exchange of data products, browse data products, 
and algorithms (as with the CDHF and DADS). A low rate (e.g., 2400- to 9600-baud line) 
can handle many of these communications, but a high speed bus will be required for the 
transfer of large data sets. 

The following three major sections describe the operations of the personnel in the TMCF. 
The three sections follow the convention for these activities as given in the MIDACS 
Functional Requirement Document, namely: 1) develop and maintain science and calibra- 
tion algorithms, 2) verify radiances and validate geophysical parameters, and 3) provide 
planning and coordination support. 

3.4.1 Develop and Maintain Science/Calibration Algorithms 

The Functional Requirements Document lists three major functions under the development 
and maintenance of science and calibration algorithms: 1) develop algorithms, 2) test and 
modify algorithms, and 3) deliver and certify algorithms. The operation of these three 
functions are described below. 

3.4. 1.1 Develop Algorithms 

Science team activities in the development and maintenance of geophysical parameter 
algorithms and calibration algorithms will be supported by the TMCF. This facility may 
also be used for comparison of MODIS derived parameters with correlative data, 
scientific quality control, and theoretical studies and modelling to the extent that the 
facilities provide sufficient resources. 

The science and calibration algorithms will be developed according to the MODIS Science 
Management Plan which is developed by the science team leader and science team 
members. Verification and validation study results will guide the algorithm testing, 
development, and maintenance. 

3.4.1. 2 Test and Modify Algorithms 

The science team members will develop algorithms for operation on the CDHF computers. 
Strict configuration control parameters will be used in coding, testing, and documentation 
of the candidate standard processing algorithms, before delivery to the CDHF. Software 
standards, such ANSI standards or EosDIS standards, will be employed as required. The 
testing of algorithms will be made to insure that both accurate results are obtained and 
that a computationally efficient approach is adopted. The science team members will use 
DQA Reports from the CDHF and correlative data to test algorithms and revise current 
algorithms. 
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3.4. 1.3 Deliver and Certify Algorithms 

The fully tested and approved algorithms will be delivered to the CDHF. The delivered 
algorithms should include the optimization, so as to achieve optimal performance on the 
CDHF. Full-scale benchmarking runs (to verify efficiency, resource estimates, and 
algorithm correctness) will be made at the CDHF in coordination with the science team 
before the new algorithms become operational. DQA and certification criteria will be 
supplied, along with the algorithm, at the time of delivery. 

The science team leader will issue Algorithm Release Announcements after the benchmark 
test for the newly delivered algorithms which will describe the data products generated 
by the algorithm and provide some information on the techniques used. 

3.4.2 Verification and Validation of Data Products 

Verification of the Level-IB spectral radiance values and validation of the Level-2 (and 
higher) geophysical parameters is an important activity of the science team members. 

The MIDACS Functional Requirements Document lists the three major activities in this 
category as: 1) receive and catalog data inputs, 2) produce special data products, and 3) 
perform correlative and modelling studies. The next three sub-sections describe these 
activities. 

3. 4. 2.1 Receive and Catalog Data Inputs 

Science team members will receive and catalog selected archive data products, correlative 
data products, selected data products direct from the CDHF, and DQA Reports. These 
data products are then ready for validation and/or verification activities. 

3.4.2. 2 Produce Special Data Products 

The science team members may produce specialized data products within the TMCF that 
will be sent to the DADS to be archived. These specialized data products could be 
prototype data products which may eventually become standard data products, the results 
of an analysis at any level of MODIS data, a series of calibration scenes for one Earth 
target, a history of lamp outputs or blackbody outputs during the course of the MODIS 
experiment, or a history of the spectral calibrations. 

Generation of specialized data products will require, at the minimum, the following 
descriptive information: 

a. A catalog entry containing EosDIS descriptions of data sources, data proper- 
ties, analysis methods, and attributes (e.g., location, time, wavelength). 

b. A standard format to allow access from EosDIS software and processing by 
EosDIS archival software. 

c. Documentation of data set contents, processing algorithms, and instrument 
characteristics. 

d. An evaluation of the results including error analysis, validation tests, and 
relevant bibliography. 

The CST will also have monitoring and analysis responsibilities which will lead to the 
generation of special data products. These monitoring duties include assuring that the 
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calibrations are within limits, defining uncertainties in all calibration coefficients, and 
updating quality control charts for gains, offsets, temperatures, lamp outputs, and so 
forth. Personnel in the CST will analyze Level-0 or -1A data provided by the CDHF to 
derive calibration coefficients. They will be looking for changes in the calibration of the 
instrument, and updating coefficients as required to meet the accuracy requirements of 
MODIS. The CDHF will receive these updated calibration coefficients from the CST. 

3.4.2. 3 Perform Correlative and Modeling Studies 

The science team members will use specialized data products, verification/validation study 
results, and received data products for correlation, statistical, and modeling studies. The 
documentation of these studies will be made by the science team members and will be 
provided to the DADS for archival. 

3.4.3 Planning and Coordination Support 

The science team members will provide input to the science team leader regarding 
instrument operation, CDHF data processing activities, and DADS activities. The science 
team leader will develop a Science Management Plan from these inputs. The functional 
Requirements Document splits these activities into four catagories: 1) receive and catalog 
requests, 2) sort and set priority of requests, 3) develop a Science Management Plan, and 
4) send requests. The next four sub-sections describe the operations involved in these 
activities. 

3.4.3.1 Receive and Catalog Requests 

The science team leader will receive and catalog all science team member and other user 
observation, data processing, and data products requests, noting if they have an impact 
on overall MIDACS operations. Standard request forms and/or interactive database 
systems will be developed to facilitate the request process. The catalog of these 
requests will be designed to interface with the general MIDACS database format. 

3.4.3. 2 Sort and Set Priority of Requests 

The science team leader is responsible for the sorting and prioritization of all requests 
and for tracking the request status. The Science Management Plan will provide a guide 
for setting priorities. Criteria for setting priorities may include considerations of the 
CDHF (processing time and data volume), the consensus science team members’ view of 
the scientific objectives, EosDIS platform considerations, and so forth. High priority 
requests may include support of field experiments and instrument state-of-health informa- 
tion. 

3.4.3.3 Develop a Science Management Plan 

The science team leader will develop a viable Science Management Plan. Components of 
the plan include judicious use of observation time, close supervision of on-going studies 
and results, dissemination of data products and algorithm information, and the steward- 
ship of the overall MODIS instrument health and operation. 

3.4.3.4 Send Requests 

The science team leader will organize and/or approve major processing requests and send 
them to the CDHF. Individual science team members will ensure that the processing 
algorithms associated with the processing requests are sent to CDHF and DADS. 
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Requests for special MODIS observation sequences will be reviewed by the science team 
leader who will resolve science conflicts and assure the Science Management Plan 
objectives are being met. The conflict free schedule will be delivered to ICC via the 1ST 
for further operation analysis using the MODIS operations simulator. 

3.5 ARCHIVE, CATALOG, AND DISTRIBUTION OPERATIONS CONCEPT 

The Data Archive and Distribution System (DADS), and implicitly the long-term archives, 
is the repository for MODIS Level-1 through -4 data. The MODIS data will be stored at 
the DADS until delivery to permanent archive centers. The IMC provides dial-up and 
local access to this data with the DADS distributing data products to users. Through 
their TMCFs, science team members will have direct access to the DADS and need not 
use the IMC/DADS access facilities. During the system’s lifespan, the DADS also 
downloads specific data to designated long-term NASA/or other archives. These data sets 
will be available only from these long-term archive facilities. The DADS will retain the 
necessary catalog and metadata to locate MODIS data at any location. 

As shown in the context diagram in Figure 10, data sets from the CDHF, TMCF, or other 
sources are supplied to the DADS for centralized storage and eventual selective retrieval 
and distribution to the general EOS community. All of this data will be available to all 
users. Even though specific data may arrive in a non-certifiable condition, it will be 
available to users with description of the data quality. Under designated circumstances, 
non-EOS access to the certified data in the DADS will be accommodated. 

As shown in the data flow diagram in Figure 11, the DADS provides for the four specific 
functional areas of receiving data products, managing data products, processing user data 
requests, and generating and distributing data products. In general the DADS is not 
expected to perform a great deal of sophisticated processing of stored data. A specified 
amount of processing will be available to designated users. The following subsections 
each represent the operations concepts for a single functional area. 

3.5.1 Receive Data 

This process consists of accepting MODIS data sets, engineering data, specialized 
products, bibliographic data, correlative data, archived data, and ancillary data. Most of 
these data are expected to be generated within MIDACS (specifically within the CDHF 
but with special data sets being generated within the TMCF), though outside investigators 
can also provide data. Bibliographic data will come from selected publications. Categor- 
ization of data sets will be based on product, scene, and land/ocean descriptors. 

The DADS may perform some degree of data compression, but it is expected to be of a 
minimal level. Browse, catalog, and metadata will be delivered to the DADS by the 
CDHF or TMCF with the same timeliness as the product. 

3.5.2 Manage Data 

This process is composed of the three subprocesses of storing data, managing catalogs, 
and status reporting for DADS operations and activities. Storing data consists of writing 
data sets to the appropriate on-line or off-line DADS storage media. When data set, 
metadata, and browse data storage are completed, the data sets are ready for retrieval in 
satisfaction of user queries. 

Managing catalogs refers to updating metadata and catalog data. Metadata data elements 
are descriptors that currently include calibration coefficients, product start and stop 
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Figure 10. The DADS Context Diagram 
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Figure 11. The DADS Functional Data Flow 




























times, data quality flags, and platform ephemeris. Catalog data elements currently 
include data set ID, type, group, location, history, and ownership. Both metadata and 
catalog entries will be available for query. Upon receipt in the DADS, metadata and 
catalog data are transmitted to the IMC where they support user query activities. 

In addition to monitoring computer resource performance and use levels, the DADS 
maintains complete records on MODIS data sets and other products that are requested by 
and provided to users. Order status is maintained and made available to users in terms 
of orders waiting for DADS data and orders pending the availability of other EOS 
archived data. Users are kept current on their balances, and accounting data are 
included in resource utilization and performance reports sent to the IMC. 

3.5.3 Processing User Requests 

The production and scheduling of catalog query and archive data products is performed 
by the DADS. For 90 percent of the time, the first data set is currently expected to be 
retrieved for DADS-resident data within 100 seconds. If off-line data sets are involved, 
90 percent of the time, the first data set is expected to be retrieved within 30 minutes. 

Up to three days may be required for retrieving data from other EosDIS DADS facilities. 
Standing orders are processed according to their periodic scheduled execution times. 

DADS access for most users is through the IMC with science team members having direct 
access through their TMCF. Some image subsetting and/or decompression may be 
possible for some data sets with the bulk of this type of processing provided by the 
CDHF as part of standard products. The DADS accepts two types of data set requests. 
The first is a result of a query processed by the IMC (or sent from a TMCF) and 
forwarded to the DADS for satisfaction. TMCF data requests are expected to be in the 
form of commands directed towards specific data sets. The second is a standing order 
on file with the DADS for a standardized group of data sets that is predicated on time, 
location, or other conditions. As data sets meeting these parameters are acquired, they 
are forwarded to the requesting user. 

For IMC-routed requests, the DADS locates the necessary data sets, notifying the IMC on 
the process. Users can request information on any of their outstanding data set 
requests. Any information pertinent to the retrieved data sets, such as instrument 
activities or reprocessing, is forwarded with the data sets. Transmission media will be 
selected on the basis of data set quantity and other factors. 

3.5.4 Generating Products and Distributing Data 

Based on the user’s preferences, data quantities, and other factors, retrieved data sets 
will be electronically transferred to a specific off-line media. Shipping/transmission to 
the user then follows. Distributed data sets include information on how they were 
generated, as well as other data pertinent to data values. Reports will be prepared on 
user activity, data sets retrieved, and other topics relevant to managing the DADS. 

3.6 USER ACCESS OPERATIONS CONCEPT 

Until transfer to long-term archive centers, the DADS is the designated repository for 
Levels-1 through -4 MODIS data sets, engineering data, specialized products, correlative 
data, and ancillary data. The DADS also provides data from other EOS DADS or from 
designated archives. The IMC/DADS contains the catalog and metadata necessary to 
access the data sets at these other facilities. 
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3.6.1 DADS Access Points 


Both dial-up facilities and hardwired terminals will be located in the IMC. Most users 
access the DADS via these facilities. Science team members have a DADS access 
capability via their TMCFs and can also use the general DADS dial-ups or terminals. 

3.6.2 User Verification 

Upon accessing the IMC and/or DADS directly, the user’s ID is validated for DADS 
usage. If it is necessary, the user’s account balance is verified as being able to pay for 
the requested data sets’ shipping. 

3.6.3 Menu-Driven Query Generation/Correction 

Users can either enter queries directly in the IMC/DADS query language, or can compose 
queries through IMC-provided menus. The latter would allow selection and combination 
of specific data elements, types of outputs, ordering of these outputs, and logical 
relationships of data element values for retrieval. This process is iterative, continuing 
until a correct query is entered or the user terminates the session. Science team 
members have the option of using this IMC-provided facility or directly entering retrieval 
commands for specific data sets to the DADS. 

3.6.4 Query by Example 

The IMC/DADS provides samples of generic queries a user can modify for his own 
specific purposes and needs. These queries may have been initially supplied by the 
IMC/DADS or by other users. The present user need only modify query components such 
as the data to be retrieved, sequencing and ordering of outputs, and the selection 
criteria, as a function of the user’s specific needs. Having been already syntactically 
and grammatically verified, these model queries can save the user considerable menu 
processing time and effort. 

3.6.5 Stored Queries 

Within a specific IMC/DADS account, the user can save previously executed queries. The 
user can execute them on a periodic basis, saving the time involved in either menu 
processing or direct command entry. These queries can also become periodic standing 
orders that, after being submitted to DADS operations, are automatically scheduled and 
executed by the DADS. Standing orders address specified areas of interest and do not 
require further action by the user. 

3.6.6 General Query Library 

Users may elect to send copies of their queries to the query library and can browse the 
query library for queries provided by other users that are relevant to their needs. 

Relevant queries can be copied into the user’s directory and modified as necessary to 
meet the user’s requirements. Prior to insertion in the library, a user provides the 
required level of documentation, including the query, describing its logic and operation in 
a standardized manner, and providing actual output to prove the query operates correctly. 

3.6.7 Data Types Provided by the IMC/DADS 

Available data types include MODIS Levels 1-4, quick-look, browse, meta, catalog, 
ancillary, bibliographical, and any specialized data sets provided by a TMCF. The DADS 
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will be able to access data sets in other EOS DADS. When requested data is located in 
a permanent (long-term) archive, the DADS will notify the user of name and location of 
that archive. 

3.6.8 User-Oriented Information Provided by the IMC/DADS 

The IMC/DADS notifies the user if the user’s present account balance is insufficient for 
retrieving and shipping the requested data sets. Upon completing the logon sequence, 
the IMC notifies users of the latest orbits for which data sets are available. For 
requests being processed the user is also notified within 100 seconds (90 percent of the 
time) of the beginning of retrieval processing. The user is also notified if requested 
data sets are available only through other archives, requiring the user to contact these 
archives directly. If requested data sets are located in other EOS DADS, the user is 
notified of the expected delays in retrieval of up to three working days. Upon request 
the user is given the status of any requests still being processed by the DADS. 

3.6.9 Disposition of Retrieved Data 

Retrieved data sets are transferred to the appropriate media (for example, computer- 
readable or hardcopy) and transmitted or shipped to the user. A specified number of 
data sets may be electronically transmitted to the user’s terminal. 

3.6.10 Billing and Housekeeping 

Users are billed for chargeable services, data set storage and shipping media, and other 
services and activities from the IMC. The appropriate entries are made to their account. 
Periodic reports are prepared on user activity, data sets retrieved, and other topics as 
directed by the IMC. 

4. MIDACS SCENARIOS 

This section presents MIDACS scenarios for the routine planning and scheduling, routine 
processing, near real-time processing, real-time processing, TOO, emergency operations, 
calibration operations, and algorithm development and implementation. A scenario for 
user access to the data produced by the above scenarios is included. A timeline of 
events is presented where possible. 

4.1 ROUTINE PLANNING AND SCHEDULING SCENARIO 

The routine planning and scheduling of MODIS is simplified by the nature of the 
instrument operational capabilities and the number and types of commandable instructions. 
Since the duty cycle of the MODIS-N and -T instruments compliment is 100% (50% for 
the reflected energy channels) and 50%, respectively, a set of commands such as those 
for the pointing (tilt), channel selection, gain, and day/night mode switching are 
uploaded. Nevertheless, the ICC must simulate the instrument resources and geophysical 
environment, and generate commands for the observation request issued by the science 
team or IWG. An overview of the routine planning and scheduling is presented in Table 
3 showing the event, lead time, and the interface of responsible facilities or centers. 
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Table 3 

Routine Planning and Scheduling Events 


Event 

Lead Time 

Interface 

1 . 

IWG science plan 

1 Month 

IWG to ICC 

2. 

Orbit prediciton 

1 Month 

FDF to PSC 

3. 

Core Resource prediction 

1 Month 

PSC to EMOC 

4. 

Special orbit product 

1 Month 

FDF to ICC 

5. 

EMOC transmit Resources & 
Guidelines 

1 Month 

EMOC to ICC 

6. 

Resource Usage predict 

1 Month 

EMOC to PSC 

7. 

Develop Initial Schedule 
using IWG plan & science 
observation request 

3 Weeks 

ICC 

8. 

TDRSS Scheduling 

3 Weeks 

PSC to NCC 

9. 

Initial Schedule Sent 

2 Weeks 

ICC to EMOC 

10. 

Conflict Resolution 

2 Weeks 

EMOC/ICC 

11. 

Schedule Core System 

2 Weeks 

PSC 

12. 

TDRSS forecast 

2 Weeks 

NCC to all 

13. 

Orbit predict update 

1 Week 

FDF to PSC to 

14. 

Active schedule issued 

1 Week 

EMOC to ICC 
NCC to PSC 

15. 

Schedule payload ops. 

1 Week 

EMOC to PSC 

16. 

Command generation 

1 Week 

ICC to EMOC 

17. 

Conflict Resolution 

5 Days 

PSC/EMOC/ICC 

18. 

Stored Commands forwarded 

5 Days 

ICC to EMOC to PSC 

19. 

TDRSS Schedule update 

5 Days 

PSC/NCC 

20. 

Core System Command 
Generation 

Days 

PSC 

21. 

Update schedlue based on 
science team request 

Days 

ICC 

22. 

Update Conflict Resolution 

Days 

ICC/EMOC/PSC 

23. 

Schedule adjust 

Days 

EMOC/PSC 

24. 

Uplink of Commands 

1 Day 

PSC 

25. 

Platform Resource update 

Hours 

ICC/EMOC/PSC 

26. 

Commanding 

-- (T) 

On board 

27. 

Command verification 

Hours (T+) 

PSC/EMOC/ICC 

28. 

Science team request for TOO 
and conflict resolution 

Hours/Days (T+) 

ICC/EMOC 
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The following paragraph gives a brief timeline of events highlighting those directly 
involving the ICC. The timeline of these events are also shown in Figure 12. The 
science team will interface with the ICC for the development of initial schedule and 
updates to resolve schedules and to initiate and develop TOO request. These interfaces 
are shown by the upper boxes in Figure 11. All times shown in Figure 12 and stated 
below are approximate. The table and figure use a reference time, T. 

T minus 4 weeks. From one month to three weeks before implimentation of the schedule 
on board the platform, the following tasks are performed. The IWG will provide the 
science plan priorities TOO procedures to the ICCs and their PI/TLs and to the EMOC. 
The IWG plan covers a four- to six-month period, begins two to four weeks after the 
end of the IWG meeting, and is distributed to the ICC. The FDF will provide any special 
orbit related products to the ICCs as negotiated. The EMOC makes a rough allocation of 
resources among the payloads of platform resources based on the IWG plan. Guidelines 
to be used in scheduling instruments will be provided as well. An example of a guideline 
could be to request that MODIS alter its operation over an area of the earth where the 
IWG has planned other instrument observations in order to avoid resource conflicts with 
the other instruments operating at that time. These guidelines would be used to reduce 
the potential for conflicts during the scheduling phase. The EMOC provides the ICCs 
with the rough estimate, guidelines, IWG plan, and orbit information. The EMOC then 
notifies the PSC of roughly how the core system resources are expected to be used based 
on the IWG plan. 

At T minus 3 weeks, using the EMOC information, the ICC will develop an initial 
schedule based on the IWG plan, the science team leader’s direction, and approved 
observation request from the science team or approved researcher requests received from 
the researchers via the IMC. All request are made to the ICC through the 1ST. The 
science team leader’s priorities and procedures are followed in developing the schedule. 
Observations that are coordinated with other instruments are scheduled in coordination 
with the other ICC. New observation requests may be input into the ICC scheduling 
process by the science team or science team leader at this time. These observation 
requests may include requests for data or instrument operations used to support routine 
data collection or field experiments. Observation requests input at this time will aid in 
the development of the TDRSS coverage required to meet these requests. The active 
TDRSS schedule may impact the timeliness of the requests at a later point in the 
timeline. 

The MODIS-N may have a simpler scheduling operation. The ICC will need only to work 
on the exceptions, for example, a safe mode for orbit adjusts, or a standby mode when 
higher priority operations combine to require that this instrument use less resources, 
near-real-time field experiment support requiring TDRSS scheduling, or a special infre- 
quent calibration mode. 

An instrument like MODIS-T is likely to be more complicated to schedule. As with many 
of the MODIS-N channels, it will only operate over the illuminated portions of the Earth 
because of dependence on visible channels. MODIS-T can also be tilted foreward and 
backward for special stereo or stare modes of operations. 

At T minus 2 weeks, the EMOC receives the initial schedule requests from the ICC. It 
identifies conflicts and resolves them by using the IWG plan and priorities as a guideline 
and by working with the affected ICCs. The ICC works with the EMOC and other ICCs 
to resolve any conflicts. The science team leader may appeal any EMOC decisions to the 
Assistant Project Scientist or the Project Scientist. Any operation tha^t is tightly 
coupled with the core system operations is coordinated with the PSC. The core system 
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Figure 12. The ICC Planning and Scheduling Timeline 






operation are then scheduled. Operations that are greatly influenced by the payload 
operations are coordinated with the ICC. 

At T minus 1 week, the ICC develops the commands to implement the schedule. The 
commands are checked within the ICC to insure that no instrument constraints or 
restrictions are violated. The stored commands are then forwarded to the EMOC. 

During the final days before the commands are implimented, the PSC, the EMOC, and the 
ICC resolve any conflicts between the payload operations and the core system operations. 
The EMOC forwards the stored commands from the ICCs to the PSC. The ICC modifies 
the schedule to accommodate late observation requests made by the science team, updated 
information (e.g., more accurate orbit data), cloud cover information, field experiment 
request, and so on. The EMOC will then resolve any conflict caused by the additional 
requests by denying the request, moving other observations, allocating unused resources, 
requesting more resources from the PSC, or requesting relaxation of platform constraints 
from the PSC (e.g., battery depth of discharge constraints). Any schedule changes are 
distributed to the ICC. 

At T minus 1 day, the commands are uploaded to the platform. 

At T, the commands are implemented for instrument control following the schedule 
developed by the ICC. 

At T plus hours or days, the ICC handles any requests for targets of opportunity. The 
science team leader, using IWG guidelines, determines whether the phenomenon qualifies 
as a TOO. The ICC coordinates the modifications in the schedule with the EMOC and 
the PSC. The procedures for observing the TOO will be predefined for many cases. 
Similar processes occur for schedule changes caused by payload, TDRSS, and platform 
problems. 

The routine scenario discussed above is only one of several routine planning and sched- 
uling processes ongoing at the ICC at any given time. Figure 13 presents a weekly 
workload for developing and generating the schedule and commands for the IWG plan or 
observation request. As shown in this figure, there will be several phases of scheduling 
that the ICC will support during a predetermined period (shown in Figure 13 as one 
week). Observation requests that may impact one schedule will, therefore, also impact 
other schedules which follow and are in a different phase of development. An example 
of this would be a TOO request made after the first T. This request would either be 
incorporated into the next week’s schedule, or result in a near-real time change to the 
current schedule, depending on when the request was made. 

4.2 ROUTINE PROCESSING SCENARIO 

Routine processing of MODIS data takes place at the CDHF. This processing requires 
the performance of three basic functions: receive Level-0 and ancillary data from the 
DHC and additional ancillary data from other sources for Level-2+ processing; manage the 
processing; and apply the algorithms to produce MODIS data products at Levels-1 through 
-4. The process management includes handling both the input data and processing 
algorithms and distributing the resulting MODIS data products. 

This scenario for the routine production of cloud parameters and outgoing longwave 
radiation (OLR) is presented here as an example of a general type of processing in which 
MODIS data will be coprocessed with data from other EOS instruments. The results will 
be atmospheric parameters such as global temperature profiles, water vapor profiles, total 
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Figure 13. The Weekly ICC Routine Planning and Scheduling Workload 






















ozone, cloud parameters, and precipitation. The data flows that describe this scenario 
appear in Figure 14. 

4.2.1 Global Cloud Parameter and OLR Algorithms 

It is assumed, in this scenario, that the processing algorithms have been developed and 
tested on TMCF computing facilities and then tested in final form on the CDHF prior to 
implementation in routine processing. 

This scenario involves the coprocessing of data from two different types of instruments. 
Data from the Atmospheric Infrared Sounder (AIRS) and the Advanced Microwave 
Sounding Unit (AMSU), which provide specific multispectral observations (complementary 
to MODIS) at a coarser horizontal spatial resolution, will have already been used to 
derive atmospheric temperature and water vapor profiles and surface temperature. These 
derived parameters are supplied as ancillary data to the CDHF, having been stored 
temporarily at the DADS until required, and then combined with thermal infrared 
MODIS-N data at relatively high horizontal spatial resolution to produce four global 
geophysical parameter data sets: 

a. cloud top pressure (mb) 

b. cloud fraction (%) 

c. cloud longwave radiative forcing (W/m 2 ) 

d. OLR (W/m 2 ). 

These four products are assumed to be produced globally at full 1 km horizontal spatial 
resolution at Level-2. Level-3 mapped cloud parameters and OLR are assumed to be 
produced at lower temporal and spatial resolution. The Level-3 data products are 
designed with the scientific application of the data in mind and will probably be the 
most useful product for the scientific community. Level-3 products will be formatted to 
be easily inserted into general atmospheric circulation models. The Level-3 format will 
also expedite scientific-validation comparisons between these and other MODIS products 
and in situ data and model calculations. 

The basic input data to the Level-2 processing are MODIS Level-IB thermal radiances at 
the full horizontal resolution of 1 km and AIRS/ AMSU Level-2 atmospheric temperature 
and water vapor profiles and surface temperatures at 50 km resolution. 

The MODIS-N IB data used here are Earth-located and radiometrically calibrated 
observations consisting of seven 15 micron and three 4.3 micron radiances that are 
sensitive to atmospheric C0 2 (atmospheric temperature), one 1 1 micron and two 3-4 
micron atmospheric window radiances (surface temperature), a single 9.6 micron radiance 
sensitive to atmospheric ozone and a single channel in the visible and near-infrared to 
measure reflected solar radiation (for a total of 15 channels). 

A retrieved temperature sounding may be invalid because of excessive cloudiness or 
nonconvergence of the solution. In this case, "6-hour forecasts" produced by a general 
atmospheric circulation model operating outside of EosDIS will be used. These "fore- 
casts" are the first guess temperature and water vapor profiles and surface temperatures 
which are produced using radiosonde temperature and water vapor measurements, surface 
measurements of temperature or climatological guesses of these profiles. These fields are 
required as ancillary data. 

The algorithms used for this type of processing will involve solutions of atmospheric 
radiative transfer equations and generally employ iterative mathematical operations. Such 
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Figure 14. Routine MIDACS Scenario For Atmosphere (Cloud Parameters and OLR) 










algorithms are computational intensive and require relatively large amounts of processing 
time. 

There are no special EOS observation sequences needed for this scenario other than a 
100% duty cycle. The data products will be produced from standard observations by 
MODIS, AIRS, and AMSU. 

4.2.2 Processing Timeline 

The TMCF will send processing requests and processing algorithms which contain the 
DQA criteria, to the CDHF. These algorithms will have been validated, tested, and coded 
according to EosDIS software standards by the TMCF. 

Level-0 data, ancillary data, and retransmitted data are received by the CDHF from the 
DHC. This data will be received by the MIDACS CDHF within 24 hours of observation. 
The CDHF will test this data against mission planning information from the ICC for 
completeness and accuracy. If any received data is unacceptable, the CDHF will send the 
DHC a retransmission request. Level-IB data will be available for Level-2 processing 48 
hours from observation. 

The Level-2 processing will combine MODIS Level-IB and AIRS/AMSU Level-2 data. It is 
assumed that Level-2 AIRS/AMSU data are available within 48 hours of observation. For 
this scenario, the CDHF will acquire AIRS/AMSU Level-2 atmospheric temperature and 
water vapor profiles and surface temperature at 50 km resolution from the DADS. The 
DADS will need to receive this data from the AIRS DADS. The Level-2 processing to 
produce the cloud parameters and OLR will then be done within 8 to 24 hours. Level-2 
processing of these parameters will have been done within 72 hours of observation, the 
same as the Level-2 MODIS products not requiring other instrument Level-2 data. 

The Level-3 processing will require as much as an additional 8 to 24 hours of processing 
time on the CDHF. It is anticipated that the Level-3 processing will produce daily 
products, and it may require that all 24 hours of the Level-2 data be available before the 
processing can begin. The CDHF will then transmit the finished Level-1, -2 and -3 data 
products to the DADS within 8 hours of the completion of the processing or within 120 
hours of observation. In the course of Levels-1 through -3 processing, the CDHF will 
generate DQA reports and send them to the TMCF. Browse data and metadata data 
associated with the standard products will be delivered to the DADS with the same 
timeliness as the products themselves. 

This scenario assumes that Levels 1-3 processing is done in sequence. The scenario 
satisfies the performance requirement that the MIDACS CDHF will process data through 
Level-IB within 48 hours of observation, but does not necessarily satisfy the Level-2 and 
Level-3, (72 hr/96 hr) performance requirements. Certainly, it should be possible to do 
some of the processing steps in parallel. In addition, the DHC will probably begin 
transmitting Level-0 processed data to the CDHF within 8 hours of the collection time. 
Hence, the delay to the Level-1 processor would be 8 hours. The Level-IA processing 
can begin before all of a 24 hour block of data has been received. The same is true of 
the Level-IB processing. 

Through the DADS, the TMCF will request the Earth Radiation Budget Instrument (ERBI) 
data from another EOS DADS to statistically validate the retrieved OLR product. This 
comparison will serve as an indirect validation of the cloud products since the OLR is 
highly dependent on clouds. GLRS data will be used to validate the cloud top pressure 
(height) retrievals. The TMCF will perform these validations after requesting subsets of 
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the Level-2 and -3 products from the DADS. TMCF validation results will then be sent 
to DADS to be archived. 

4.3 NEAR-REAL-TIME PROCESSING SCENARIO 
4.3.1 Planning 

The MODIS science team keeps the science team leader informed as the planning for an 
upcoming field experiment develops. Specific information of interest includes the start 
date and duration of the experiment, its location, the MODIS Level-1,2, and 3 data 
required, and the timeliness requirements for the data. This communication occurs within 
the distributed TMCF and also involves an interface to the science team leader at the 
1ST. 


4.3.2 Delivery of Support Plan 

The planning concludes with a formal plan for the field experiment, as well as the 
definition of the MODIS near-real-time data sets required to support the experiment. 
The experimenter delivers the plan electronically to the team leader at the TMCF and 
the IMC for approval. In this scenario, as an example, the plan is as follows: 


Experiment Purpose: 
Experiment Start Date: 
Experiment Duration: 
Experiment Location: 
Timeliness Requirements: 


Coverage Requirements: 


Level-IB Data Required: 

Level-2 Data Required: 
Level-3 Data Required: 


Examine Gulf Stream frontal boundary 
December 17, 1998 (in 60 days). 

14 days 

Cape Hatteras, NC, and neighboring Atlantic Ocean 
Daily; within six hours of real time (to support in situ 
measurements taken by three oceanographic vessels, 
directed by the team member in response to the MODIS 
parameter behavior 

A single MODIS scene (2000 km square); 
two scenes every third day depending on 
the POP-1 orbit. 

15 channels MODIS-T (without sunglint); 2 channels 
MODIS-N 

15 standard products 

10 products on 10 km MODIS standard grid 
5 products or 1 km MODIS standard grid 


4.3.3 Scheduling and Commanding 

After review, the team leader approves the data request and forwards it via the 1ST to 
the ICC as an "observation request." Following predefined procedures for planning and 
scheduling, the ICC tests the plan on the simulator and then reviews the plan with the 
EMOC to test for conflicts. After approval of the plan by the EMOC, a "command load" 
is generated and sent to the EMOC/PSC. The command load assures that the MODIS 
instruments will observe the experiment region at a given time and that the data will be 
designated by the on-board processor for near-real-time processing by the CDHF. This 
command procedure is tested by generating command loads to tag data for production of 
a near-real-time trial scene for the target region well in advance of the experiment (as a 
rehearsal). 
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4.3.4 Data Processing 

The CDHF is notified by the team leader via a "TMCF Processing Request" to anticipate 
the near-real-time data. The request provides the exact processing requirements. The 
automation code in the CDHF is programmed to provide the near-real-time processing for 
the experiment as requested. The CDHF tests the data processing software and proce- 
dures by processing the trial scene and produce the requested scene data in near-real- 
time and delivering it to the DADS as "Archive Data Products." 

4.3.5 Data Archival and Distribution 

The DADS is notified by the team leader to anticipate the receipt of the near-real-time 
data as soon as it is generated from the CDHF and is provided with the delivery address 
and communications methodology for delivering the data to the experimenter. The DADS 
verifies the delivery procedure by receiving, storing, and then transmitting the data from 
the trial scene, as well as the requested scene data, in near-real-time within the required 
timeliness. 

4.3.6 Monitoring and Evaluation 

Both the scientist concerned and the team leader are kept apprised of the outcome of 
the trial scene experiment, as well as kept regularly informed (daily) of the status of the 
near-real-time processing as the experiment takes place. Corrective action is taken if 
required. The scientist and team leader evaluate the success of the near-real-time 
support shortly after the conclusion of the experiment. 

4.4 REAL-TIME PROCESSING SCENARIO 

Real-time here refers to two separate data streams. The first one is engineering data 
collected and transmitted to the TDRSS without buffering. The second type is playback 
data that is transmitted to the ICC without buffering at DIF and DHC. Both types of 
real-time data are needed to monitor the MODIS instrument for the health and safety. 

The second type is needed to support field experiments. The output from this monitoring 
can be used to correct anomalous instrument behavior or aid in field experiment deci- 
sions. A scenario to monitor the science data in real-time is presented here and shown 
in Figure 15. 

To provide this requirement, the MIDACS will need to manipulate the selected MODIS 
science data return in real-time. This data will be separated into selected MODIS-T and 
-N bands that result in building of scenes of data that are (2000 km) 2 in coverage. 
Investigators will select the specific spectral bands of interest in real-time at ICC. 

4.4.1 Delivery of Real-Time Plan 

In a field experiment support scenario, the real-time plan begins with an observation 
request by the science team leader that is implemented by the ICC into the planning and 
scheduling scenario. This request may be implemented as routine, or as an update to an 
ongoing observation. In either case, the request for real-time instrument data must be 
coordinated with the TDRSS schedule generated at the Network Control Center (NCC). 
This is done to provide real-time science data at the selected field experiment site. The 
experiment team member uses this observation data to develop field experiment criteria 
and strategies. After review and approval by the experiment team, the observation 
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request is forwarded to the ICC via the 1ST. In the following scenario the plan is as 
follows: 


Scene start time: 
Number of Scenes: 
Duration of Scene: 
Instrument requested: 
Selected Channels: 
Processing Level: 


Orbit 2 of December 17, 1998 
One 

5 minutes 
MODIS T and N 

1 through 4 for MODIS T & N (ground support) 
0 ( ground support) 


The ICC then uses the observation request in a simulation to ensure the correctness of 
the request and reviews it with the EMOC as in the planning and scheduling scenario. 


4.4.2 Data Processing 

For both types of scenarios, the ICC will receive data from the DHC. The DHC, with 
appropriate information for identification of the MODIS real-time instrument packets, 
then routes the instrument packets in real-time to the MIDACS. It is anticipated that 
the DHC will transmit all MODIS engineering data received in real-time to the MIDACS 
for health and safety monitoring. For field experiment support, the experiment team has 
the option of using playback data in a priority mode. The playback data will contain the 
requested data and will be downlinked on the next TDRSS contact following the 
requested quick-look time. If the experiment team is using playback data for quick-look 
analysis, then the data request sent to the DHC contains the requested start and stop 
times for a segment of the playback data to be sent to the MIDACS without level zero 
processing. 

4.4.3 Science Data Monitoring 

The DHC electronically transmits the real-time or playback segment of instrument packets 
to the MIDACS where they are stored, buffered, and the bands to be monitored are 
selected. The selected bands are then processed to the requested level and displayed on 
workstations in the ICC (separate workstations for MODIS-T and -N). Up to four bands 
can be selected, per instrument in real-time, by a science team member located at the 
ICC. Only the quick-look data that is selected is stored. 


4.4.4 Evaluation 


The science team member monitoring the MODIS science data will appraise the status of 
each selected band. From this appraisal a request can be made to correct anomalous 
instrument behavior and to direct field experiment activities. Monitored data will be 
stored at the ICC for analysis of instrument health and safety at a future time. 

4.4.5 Quick-Look Architectural Issue 

At this time, it is estimated that the MIDACS element receiving the direct real-time 
MODIS data must have a MIPS rating of greater than 70 just to sort and select the 
desired quick-look channels. Since this is several orders higher than required to support 
an ICC’s control and monitor function, the quick-look data may have to be processed to 
the desired level at the CDHF prior to display and manipulation at the ICC. 
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4.5 TARGET OF OPPORTUNITY (TOO) SCENARIO 


Dynamic phenomena, such as volcanic eruptions, insect infestations, and human produced 
or related events, will be detected by MODIS. These events represent targets of oppor- 
tunity for scientists and require a quick response both by the scientist and MIDACS to 
study these phenomena. The scientist, presented in this scenario as a science team 
member, will notify the science team leader of an ongoing or predicted target. Specific 
information necessary to operate the MODIS instruments to study this event will result 
in the generation of command or observation request by the science team leader which is 
sent to the ICC via the 1ST. These requests will impact the current schedule at that 
time. 

4.5.1 Planning 

Since the majority of TOO events may not be predictable, the following scenario 
discusses MIDACS operations for an unpredicted event. The request does not follow the 
current instrument schedule. Researchers or a science team member deliver a TOO 
request to the science team leader at the TMCF, the 1ST or the IMC for approval. The 
approved request is then transmitted via the 1ST to the ICC. As an example, this 
observation request may contain the following information. 

TOO type; Red Tide 

TOO start time and duration; 1998, July or August, 3 days 
TOO location; Gulf of Mexico 
Timeliness requirement; Daily, 3 days 
Near Real-time requirements; First day 
Instrument Unique Operations; MODIS-T tilt 

The TOO scenarios are similar in nature to the Near Real-Time scenarios when the 
observation data needs to be processed quickly. 

4.5.2 Scheduling and Commanding 

The IOT at the ICC will respond in an appropriate manner to the request. To minimize 
turnaround time, the ICC may use pre-generated commands developed for such an event 
or generate the commands from a simulation of the request. The latter may be a 
shortened process due to the nature of the request. The command load is then verified 
and sent to the EMOC for resource conflict review. The commands are then uploaded to 
the instrument according to standard procedures during the next available TDRSS contact. 
If the event is to be observed in near real-time, command loads will be generated to 
assure that the instrument properly tags the instrument packets for near-real-time 
processing. Once the TOO event is over or the duration time span of the observation 
request to monitor the TOO is exceeded, commands will be issued by the IOT to resume 
the current weekly schedule that was interrupted. 

4.5.3 Monitoring 

The ICC will notify the CDHF of the request in order for the CDHF to provide the 
appropriate processing functions and will notify the science team leader of the status of 
the request. The IOT will monitor the engineering and science data to ensure that the 
instrument is responding to the command load. If an anomaly is discovered in the 
operations, corrective action will be taken by the IOT the approval of the science team 
leader. 
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4.5.4 Data Processing And Archiving 

Processing of observation data for targets of opportunity will follow near real-time 
processing requirements closely. The CDHF will contain or be provided with an automa- 
tion code to provide the near real-time processing for the event as requested. The 
DADS will be notified by the science team leader to anticipate the receipt of the TOO 
data as soon as it is processed. As in the near real-time processing scenario, the DADS 
verifies, stores, and transmits the data to the originator of the request. 

4.6 EMERGENCY OPERATIONS SCENARIO 

An emergency command situation may be detected in several ways; by the onboard 
computer system, from observation of the MODIS instrument by the IOT within MIDACS, 
or from an EMOC request due to other instrument behavior. If MODIS exceeds its 
operational resource envelope, the onboard flight data system may safe the instrument. 

It will then be the responsibility of the IOT and the science team to determine and 
correct the condition. We assume that anomalous behavior of the MODIS instrument, 
resulting in the emergency situation in this scenario, is discovered by the IOT and the 
science team during the course of routine monitoring of engineering and science data. 

For the following scenario, a detected failure in the mechanical operation to tilt 
MODIS-T is used as an example. 

4.6.1 Routine Monitoring of Instrument Behavior 

The IOT located at the ICC will monitor the engineering and ancillary data from the 
instrument and the platform. The data will be analyzed by the IOT using predefined 
checks and procedures, such as limit checking against expected parameters. The expected 
parameters will be derived before launch by the instrument design engineers, the CST, 
and the science team. Algorithms used to monitor the engineering data will also be 
develop by the CST and science team and incorporated into the ICC monitoring proce- 
dures. The ICC will be manned 24 hours a day to ensure the constant monitoring of the 
MODIS instruments. 

Science data will also be monitored in the ICC. This task will be accomplished by a 
science team member using a workstation in the ICC. A selected set of up to four 
channels will be simultaneously monitored to analyze the collection and quality of science 
data. 

4.6.2 Detection of Anomalous Behavior 

We assume here that, during the daily observation of engineering data it is discovered 
that the power for the control of MODIS-T tilting is below its minimum limit check 
parameters. The IOT then verifies that the ingested engineering data is correct and 
current within the MIDACS itself. The science data monitoring function is also checked 
to determine if the results concur with the engineering and ancillary monitoring results. 
The science data scene indicates that the current command load for MODIS-T tilt is not 
pointing the instrument in the proper direction. These checks are accomplished in a 
timely manner. The EMOC is then notified of the condition to warn other instruments 
of an anomaly in the platform resources. The IOT will concurrently contact the science 
team leader to verify the condition as an emergency condition and to jointly determine a 
response to correct it. 
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4.6.3 Emergency Response 

The IOT has analyzed instrument behavior during the prelaunch phase and most emer- 
gency command situations (e.g. safing) have been anticipated. Critical command loads 
that were pregenerated and waiting to be transmitted to facilitate a rapid response are 
then brought on-line. The pre-generated commands are updated in response to the 
understanding of the instrument behavior. This is also done whenever possible to cover 
new or previously unanticipated instrument behavior possibilities. The IOT then sends 
the pregenerated command to place the instrument into a safe mode, such as a nadir- 
pointing orientation. If this command does not correct the condition, procedures are 
then followed to take future corrective action. This action may simply be to accept the 
current tilt angle until instrument and platform engineers analyze the anomaly and 
recommend corrective measures. The instrument is then safed according to approved 
procedures by uploading a new safing command. 

4.6.4 Analysis of Emergency 

Once the instrument has been safed or the condition corrected to the approval of the 
science team leader, analysis begins to determine the cause of the condition. This is 
done using data archived within the ICC and the DADS, along with the analysis taking 
place both by the IOT at the ICC and by the CST within the GSFC TMCF. The cause in 
this scenario was a power decrease due to a temporary degradation of the solar panels 
on the platform. After the power level resources were resolved and other instrument 
power resources reduced, commands were sent to MODIS with the next scheduled upload 
to resume the current operations plan for tilting. 

4.7 CALIBRATION OPERATIONS SCENARIO 

The scenario presented here provides a chronological summary of how calibration 
operations may proceed, who will be involved, and how they will interact. Since the 
scenario assumes that calibration planning is done in one week blocks, most of the steps 
in the scenario will be occurring simultaneously as each of the weekly plans progresses 
through the system. 

T - 5 weeks: The CST consults with the HIRIS CAL and with other instrument calibra- 
tion teams on the EOS platform, informing them of the upcoming calibration plans. The 
calibration observation plans of the two or more instruments are coordinated so that 
instrument intercomparisons are possible. 

T - 4 weeks: The CST decides on a schedule of observations that they want for a one 
week period, four weeks in the future. They wish to examine intensively their Earth 
targets of opportunity. The calibration scientist, or his designate in the CST, using an 
interactive menu-driven program developed jointly with the IOT, determines the times 
(GMT) and orbit numbers when the EOS platform will be over the selected targets within 
10 degrees of vertical during the week in question. The CST incorporates this derived 
information in the proposed observation plan, an example follows. 

4.7.1 Initially Proposed Weekly Schedule 

All days: Deploy solar diffuser plate on one orbit each day as satellite crosses the 
Earth’s terminator (nearest 00 GMT). 

Day 1: Normal operations. No special mode changes. 
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Day 2: Observe Earth targets: White Sands, the central Sahara, 

the Atacama desert, and Greenland during orbits n, n+3, 
n+4 and n+9. 

MODIS-T in nadir position. 

During a night orbit, sequence lamps through 3 levels. 

Tag all special data sets for CDHF/TMCF. 

Day 3: Observe Earth target: South Pacific region. 

MODIS-T in nadir position. 

Tag data for CDHF/TMCF. 

Day 4: Night time orbit: observe dark side of Earth, perform 

spectral calibration, and perform electronics calibration. 

Tag data for CDHF/TMCF. 

Day 5: Observe targets: White Sands, the central Sahara, the 

Atacama desert, the South Pacific region, and a second 
South Pacific region. 

MODIS-T in nadir position. 

Tag data for CDHF/TMCF. 

Day 6: Observe targets: the Arabian peninsula, Alice Springs, and 

the Kalahari Desert. 

MODIS-T in nadir position. 

Tag data for CDHF/TMCF. 

Day 7: Observe targets: White Sands, the central Sahara, and the 

two South Pacific regions. 

MODIS-T in nadir position. 

Tag data for CDHF/TMCF. 

4.7.2 Scheduling and Commanding 

T - 3 weeks: The science team leader received the proposed plan from the CST one 
week ago. He also received proposed observation plans from several other science team 
members and from other users via the IMC. As part of the initial screening process, the 
plans are entered into an expert system on a computer which identifies possible conflicts 
in observations. The science team leader and science team members are provided with 
copies of the list of observation conflicts. The science team leader in consultation with 
the science team members reviews the conflicts. The CST proposal to observe the 
Atacama desert on days 2 and 5 requires MODIS-T to be in the nadir position which 
conflicts with proposed ocean chlorophyll observations requiring MODIS-T to be in a tilt 
position. The science team leader decides ocean chlorophyll measurements have higher 
priority based upon IWG guidelines and eliminates the Atacama desert observations from 
the CST observation plan. The conflict free plan is sent to ICC using the 1ST. 

T - 2 weeks: ICC tests the plan on their simulator and finds no problems. ICC in 
consultation with EMOC reviews the impact of the plan on the platform operations. In 
this case we assume a conflict is found requiring the CST to cancel or re-schedule the 
night observations of the lamps scheduled on day 2. ICC notifies the science team leader 
who in turn notifies the CST of the conflict. The CST revises their plan to have the 
night observations on day 3 rather than day 2. The conflict resolution procedure 
described above is repeated with no further observation changes required in the second 
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go-round. The HIRIS CAL and other instrument calibration teams are kept informed of 
all developments within MIDACS relating to the coordinated calibration plan. 

T - 1 weeks: The ICC writes the command sequences which will be executed in the 
following week. These command sequences will include a tag which will be appended to 
the header of the data requested by the CST so that they can easily identify the data 
sets that they requested. An alternative scenario would require the CST to simultane- 
ously notify CDHF of the observations plan and require CDHF to somehow extract the 
requested data from the data stream. 

T + hours: However the data is extracted, the CDHF writes the data to a disk on an 
account maintained by the CST at the CDHF. A mail message is sent to the CST 
notifying them that new data has arrived. The CST downloads the new data to their 
TMCF for more detailed analysis. 

T + 12 hours: The CST uses the newly acquired data to derive gains for the detectors. 
Based upon this analysis, the CST decides that several detectors have changed suffi- 
ciently that revised calibration coefficients are required. An updated table of coeffi- 
cients is sent to CDHF with the time at which it becomes effective. The CDHF uses the 
coefficients in its routine processing of Level-IA data to Level-IB. Simultaneously, the 
CST sends this information to the DADS for archiving. 

T + 3 days: The CST contacts the IMC and requests the HIRIS data taken in the plan 
be sent from their DADS to the CST. 

T + 5 days: The CST receives the HIRIS data. 

T + 1 week: The CST uses the Earth TOO data for more detailed analysis of the MODIS 
instrument performance. Much of this analysis may be of the form of interactive image 
processing using a version of the Land Analysis System (LAS) software of Landsat or 
PACE (the software package used by the Canadian Centre for Remote Sensing). Typically 
the HIRIS spatial and spectral resolution would be degraded to match the MODIS 
resolution and then the differences between the two equivalent images would be studied. 
These analyses may confirm previously observed instrument changes have occurred, may 
lead to re-processing, or the development of new calibration algorithms. 

The following provides some comments on how the derivation of the calibration coeffi- 
cients might proceed at around T + 12 hours. The CST is responsible for maintaining the 
calibration of the MODIS instruments in orbit. One of their performance requirements is 
that they derive revised calibration coefficients in sufficient time such the processing of 
Level-IA data to Level-IB radiances is not delayed. A second performance requirement 
stipulates that Level-IB processing be complete within 48 hours of receipt of Level-0 
data. Three alternative scenarios present themselves: 

a. The calibration coefficients are automatically derived using the CDHF and 
normally there is no additional examination of the data by the CST. This 
scenario is highly probable, and it is likely that one entire orbit’s worth of 
data will be used to derive the calibration coefficients. 

b. The CST has the capability to examine a subset of Level-0 data. Since 
Level-0 to Level-IA processing will take about 24 hours, this time period can 
be used by the CST to derive calibration coefficients. 
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c. The CST has the capability to examine Level-IA data. This case would leave 
the CST very little time for analysis. 

The actual scenario that will emerge is as yet undetermined. 

4.8 USER ACCESS SCENARIOS 

Two typical scenarios are presented to typify the types of user access to the DADS, the 
retrieval/shipping of selected data sets, and support of specialized user activities. 

4.8.1 A Science User Who Relies on System Menu Processing 

A research scientist is trying to determine the scope of MODIS data available with 
information content related to ocean and lake biological activity. The scientist works at 
an institution with a current MODIS account. The scientist comes to the IMC and 
reviews the hardcopy catalog entries in his areas of interest and looks at the low 
resolution browse data in the browse publications. After making preliminary notes on the 
geographic areas containing the desired levels of the parameters of interest (e.g., 
chlorophyll, surface temperature), he logs into the system on one of the hardwired 
terminals. 

The scientist first accesses the literature search menus and selects a keyword-based 
search using relevant parameters and specific techniques of analysis. The system locates 
15 publications, and the applicable journal articles’ abstracts are queued to the terminal. 
The system also indicates which articles are based on MODIS data or other data acces- 
sible through EosDIS. The scientist selects seven for printout in the IMC. The process- 
ing for these services is billed to the institution’s account. 

The scientist now selects the MODIS data selection menus and requests images identified 
from a metadata-based search. These Level-2 and Level-3 product metadata values 
include chlorophyll concentration ranges, chlorophyll fluorescence ranges, times of 
observations, measures of cloudiness, and calibration quality flags. Because of the 
scientist’s interest in modified retrieval methods for some of the parameters, the scientist 
also requests the Level-IB data used to generate these products and their processing 
algorithms (including documentation and sample benchmark data). The scientist also 
selects the option of having these algorithms and their documentation printed in the 
IMC. 

Within 15 seconds the system notifies the scientist (via his terminal) his query has been 
queued for execution and asks for confirmation for the charges being made to the 
institution’s account. Confirmation is given in the form of the scientist’s individual user 
code. Ten minutes later a message appears indicating the first of the 350 datasets 
meeting the retrieval criteria has been located. The off-line media will be available for 
shipment by 3:30 PM of that same day. The system recognizes the scientist’s terminal to 
be an IMC terminal and the scientist is given the option of either having the products 
(optical tapes in this case) shipped or taking personal delivery. He selects the latter. 

The system acknowledges and provides an order number and tape numbers to be used 
when he requests the tapes from the data clerk. 

Using the menus the scientist requests a second look at the eight articles he did not 
select for printing. He then selects two of them for printing in the IMC. The institu- 
tion’s account is accordingly billed. The scientist uses the menus to check the progress 
of his dataset order and logs out of the system. 
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4.8.2 A First-Time Knowledgeable User 

In May, 2007, a researcher is studying the change of effluent characteristics on the 
Mississippi River over the past 10 years. The researcher needs spring and fall MODIS-N 
Level-IB imagery with less than 20 percent cloud cover. This user is a non-NASA 
funded university researcher who knows the instrument, location, and time coverage. 

The user first contacts an EosDIS representative to set up an account on the EOS 
system. Billing arrangements are made with the university and the user is given a 
unique EOS user ID. 

From a university terminal the user logs into the IMC to locate the available data. The 
user already knows the MODIS data (channels and processing level) relevant to his 
research and wants to review any similar research previously performed with the EOS 
data. Using the menus he selects the option to review published papers identified with 
keywords such as "effluent", "sediment", "turbidity", and "Gulf of Mexico". Several 
papers are read and selected for transmission to his terminal. The cost and target 
address are user-verified and the material is sent. 

Through the selection menus the user specifies metadata values in terms of date/time, 
latitude, longitude, specific channels, and less than 20 percent cloud cover and/or 
sunglint. The system provides a list of available images, their geographic limits, and any 
quality control flags. Selected browse data meeting the query criteria are viewed. 

The user selects the order menu and the desired images are identified for copying to 
computer-readable media and subsequent shipment. The user repeats the 
query/browse/ordering process for each relevant time period and geographic area. For 
selected images the system provides processing documentation such as instrument 
calibration and processing algorithm information. 

After the user indicates the session is completed, the DADS displays completed order 
forms on his terminal. These forms list the images requested, supporting documentation, 
media to be used, and the cost. The user verifies the forms’ data and the order is 
queued for processing and shipment. 

4.8.3 Science Team Member Validating a New Level-2 Product 

A scientist on the MODIS science team needs data to study a new Level-2 terrestrial 
vegetation index being produced as a standard product within the CDHF. The required 
data will be a Level-2 and -3 data set of vegetation types from a few selected study 
regions that coincide with a recent period of interest. 

As a science team member, the scientist knows the parameter of interest (10 km gridded 
vegetation indices), the time period required (the first 10 days of the current month), 
and that the MODIS data were acquired within the two geographic areas and periods 
selected. The scientist logs into the DADS through the TMCF. The scientist requests 
the data sets meeting his needs. They are copied to the appropriate media and shipped. 

The scientist logs out of the DADS and into the IMC. This gives access to the selection 
menus for performing a search of the relevant literature. (TMCF-based access to the 
DADS requires the user to issue specific data set retrieval commands. The IMC provides 
menu processing and query generation.) Several archived publications, as well as the 
algorithms and other standard documentation, are located through a keyword search and 
transmitted to the scientist’s terminal. 
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The TMCF provides the scientist with the computing support necessary for performing 
research with the Level-2 product. 

4.9 ALGORITHM DEVELOPMENT AND IMPLEMENTATION SCENARIO 

Algorithm development and implementation will be occurring both prior to launch and 
after launch. In this scenario, we list some of the steps that may be encountered in a 
typical developmental program with a typical time line. 

T - 5 years: The science team member receives sufficient computing resources from the 
MODIS Project Office so that he can start algorithm development. (T is the implementa- 
tion date and possibly the launch date.) 

T - 2 years to T - 2 months: A prototype algorithm is developed and debugged by a 
science team member. It is submitted to the CDHF for timing tests. Computer scientists 
at the GSFC TMCF node and CDHF begin examination of the software code and look for 
methods to increase the efficiency such as vectorization. The science team member 
continues to check the accuracy and validity of the algorithm. 

T - 2 months to T - 1 month: Using lower level MODIS data generated by the CDHF 
and using the CDHF computers, the science team member and computer scientists have 
interacted to increase the code efficiency, with runs requiring about 1/3 to 1/100 the 
computer time that the initial code required. No loss in accuracy has occurred and the 
CDHF computer architecture is fully exploited. 

T - 1 month: The algorithm is formally delivered to the CDHF by the science team 
member, along with all certification and DQA criteria needed for autonomous processing. 

T - 1 week: The CDHF automated/expert system processing code is updated to bring the 
new algorithm on line. 

T: The algorithm is applied to Level-1 B data and generates a Level-2 product. Browse, 
metadata, and catalog data are generated. The certification criteria are tested. 

T + 1 day: DQA indicates a change in the algorithm is needed. For the purposes of this 
scenario, we assume that the initial validation tests indicate a problem exists with the 
algorithm and that the certification criteria are not being met. The CDHF withdraws the 
algorithm from routine processing. The defective data are sent to the DADS as uncerti- 
fied and are only available to the science team. 

T + 2 months: The science team member has located the problem in the code and fixed 
it. The revised algorithm is resubmitted to the CDHF and the CDHF reinstalls it in its 
Level-2 processing stream. 

T + 2.2 months: Archival of the geophysical parameter starts since it is now a certified 
standard product. The science team leader, based upon the most recent validation 
studies, certifies the algorithm and issues an Algorithm Release Announcement. Simul- 
taneously, retroactive processing on the backlog of data, taken prior to the implemen- 
tation of the algorithms, is used to derive the new standard product. The required 
input data is acquired from the DADS and sent directly to the CDHF for processing at 
twice the processing rate. 
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T + : As the MODIS experiment continues, the scientific algorithm is updated and 
maintained as required. The maintenance of algorithms is an ongoing aspect of the 
experiment. 

5. OUTSTANDING ISSUES AND UNCERTAINTIES 

With an expected launch of the NPOP-1 in late 1996, we have some eight years to wait 
before the first data taken in flight by the MODIS-N and MODIS-T instruments is 
received and processed. Before this milestone is achieved, the MODIS data system must 
be fully designed, built, and tested. At this stage, however, the Phase-B design studies 
for the instruments are not yet completed, the members of the MODIS science team have 
not yet been selected, and the structure and concept of the EosDIS is still evolving. It 
is not surprising that there exist some uncertainties, at this time, in specific areas of 
the MIDACS operations concept. The uncertainties fall into two categories: those driven 
through a lack of specific definition of the EosDIS environment and those driven due to 
a lack of specific knowledge concerning the MODIS instruments’ capabilities and the 
science team members’ proposed research objectives. 

5.1 REAL-TIME MONITORING OF MODIS DATA 

Engineering and science data taken by the MODIS instruments, as well as selected 
platform ancillary data, must be monitored in the ICC. Ideally, all data of possible 
utility would be available in real time with a 100% duty cycle. However, the primary 
downlink will be through the TDRSS, and it is anticipated that the platform will have 
access to the TDRSS for only portions of each orbit. Each TDRSS access will be 
generally scheduled well in advance of the actual contact. While there will be an 
alternate multiple-access low-rate data path for the transmission and verification of 
emergency commands, the TDRSS link will be the sole path for downlinked data destined 
for the monitoring function within the ICC. Engineering and science data taken between 
TDRSS contacts will be stored on board the platform for playback and downlink at the 
time of the next TDRSS contact. 

Under these circumstances, it will not be possible to monitor the instrument with a 100% 
duty cycle in real time. With priority-playback processing at the DHC, the data may be 
monitored with a 100% duty cycle either in real-time or shortly after reception by the 
DIF. It is anticipated that the platform and instrument ancillary data (engineering/ 
housekeeping) will be packetized separately from the science data and automatically 
routed to the ICC. 

There is a requirement that science team or IOT members located in the ICC monitor 
four channels each of MODIS-N and MODIS-T data in real time, and that the choice of 
the channels being monitored be selectable in real time. Even though the first method is 
used in this report, there are three possible methods for achieving this: 

a. The data are buffered on board the platform by the instrument data system 

during each scan. Data from different channels are packetized separately. All 
MODIS data is treated as either real-time or priority-playback data by the 
DHC. A split pipe flow may exist, with Level-0 processing functions performed 
twice for some MODIS data, allowing the MODIS ICC to receive the data 
quickly and the CDHF to receive the data after the gaps in coverage have 
been filled. Within the ICC, the headers of the Level-0 data packets are 
examined and data from selected channels only are ingested into the moni- 
toring data base; non-selected data are lost. 
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b. As in the previous example, the science data is buffered and reorganized prior 
to the generation of data packets. However, in this scenario, the ICC uplinks 
to the on-board data system in real-time the selected subset of channels to be 
monitored. The on-board data system installs the real-time/priority-processing 
designation and ICC address in the header of the packets of data required for 
monitoring. Upon acquisition at the DHC, the designated packets of data are 
delivered immediately to the ICC, perhaps with only partial Level-0 processing 
Within the ICC, the data are received at a relatively low rate, unpacked, and 
inserted into the monitoring database. Data from unselected channels are not 
available with this timeliness, but may be analyzed at a later time (24+ hours 
after observation) upon completion of processing at the CDHF. 

c. In this case, we assume that the on-board processor does not buffer the 
MODIS data during a scan (on the order of ten megabytes for MODIS-T). 

Each packet of science data then contains data from many spectral channels 
multiplexed together. All MODIS data is treated as either real-time or 
priority-playback data by the DHC. As with the first example, there is no 
interactive, real-time selection of channels to be monitored between the ICC 
and the on-board processing system. Because of the absence of on-board data 
sorting by channel, the science data required for monitoring at the ICC must 
be collated from observations contained on many packets. All MODIS data 
packets are required, and many aspects of the Level-0 and -1A processing are 
required to unpack and reorganize the data into a form useful for monitoring. 
The processor size required will exceed that normally associated with typical 
control and monitor functions and may reside on the CDHF. 

5.2 IMPLEMENTATION OF ALGORITHMS FOR STANDARD PRODUCT PROCESSING 

A significant savings in required computing resources can be made if algorithms are 
written to take advantage of the machine architecture. As the operations concepts is 
now written, a group of computer scientists at the GSFC TMCF node will be engaged in 
this activity, although as yet this group is not formally identified in other documents. 
They could also be useful to science team members by developing algorithms of general 
utility to all science team members such as subroutines that could re-image any geophys- 
ical data onto a regular'grid. This single development would save each of the science 
team members from developing the same subroutine. 

5.3 CAPABILITIES OF THE ON-BOARD PROCESSOR 

5.4 NON-MODIS INSTRUMENT DATA AVAILABILITY 

Non-MODIS instrument data availability from other EOS and non-EOS sources. 

5.5 NEAR-REAL-TIME DATA COMMUNICATION 

Communication of near-real-time data from the CDHF/DADS to field experiments. 

5.6 DATA PROCESSING OPERATIONS CONCEPT 

The level of meaningful detail in the processing operations concept is limited by our 
knowledge of the processing algorithms. Details of the processing scenarios and concepts 
such as the logical data record. Earth location, and calibration accuracy will evolve with 
our understanding of processing algorithms and end-user requirements. 
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| 5.7 CAPABILITIES AND INTERFACES OF THE MIDACS WITH THE DHC 

I What are the current capabilities of the DHC to support the real-time, near-real-time, 

I and routine science data processing timelines that are required by the MIDACS? The 
[ DHC will process some data for real-time delivery to the MIDACS (ICC or CDHF) for 
monitoring. The DHC will also pass the priority playback data to the MIDACS, but it is 
still uncertain how this will be accomplished. This DHC/MIDACS interface has not been 
i fully clarified. 

5.8 ON-BOARD PROCESSING 

j There will be an impact to the ICC workload for the planning and scheduling/control and 
monitoring functions if the ICC has the added responsibility of uplinking commands for 
the selection of channels to be monitored. The ICC personnel would have to work more 
directly with the EMOC/PSC/NCC for the scheduling of TDRSS contacts to accomplish 
this. Also, the increase of work due to many requests for data or the rapid selection of 
channels would pressure ICC personnel to make quick decisions without the ability to 
follow defined procedures and guidelines for the checking and verification of all command 
' loads. 

1 

5.9 STORAGE OF THE MODIS SCIENCE, ENGINEERING, AND ANCILLARY DATA 

These data will be stored either at the ICC, EMOC, or MIDACS DADS. This has an 
impact on the required storage capacity of ICC or wherever the data are stored. 

5.10 IMPLEMENTATION OF DARs FOR REAL-TIME FIELD EXPERIMENTS OR 
INSTRUMENT CALIBRATION 

The current schedule will be interrupted for each request. The number of such requests 
is unknown at this time. .Any request for real-time support would effect the TDRSS 
scheduling and, therefore, needs to be coordinated with the appropriate facility to satisfy 
the reqest. 

5.11 HIERARCHY OF REQUESTS 

The hierarchy of priorities for the requests for field experiments or real-time monitoring, 
and the availability of workstations at the ICC to provide support, must be defined. 

k 5.12 COMMAND TRACKING OF TOOs AND REAL-TIME REQUESTS 

The ICC must verify the command load for all commands uplinked to the MODIS before 
they are transmitted to the EMOC. The procedure and timeline for doing this must be 
defined. 

5.13 MODIS/HIRIS AND JOINT SCHEDULING WITH OTHER INSTRUMENTS 

The MODIS and HIRIS will have some sort of interaction not only for the planning and 
scheduling phase, but also for the impacts of requests for data in the real-time and 
near-real-time for the support of field experiments for MODIS and coincident observa- 
1 tions for HIRIS. A prioritized scheduling process must be developed. 
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5.14 MIDACS SUPPORT PERSONNEL 

The role of the product support analysts and the system operators with respect to the 
production of standard data products. 

5.15 ERROR CORRECTION/GRADE OF SERVICE 

Will the MODIS data be encoded (e.g., Reed-Solomon) for error correction and error 
corrected to a bit error rate of 10' 10 to 10~ 12 ? At 10‘ 12 , on average only one bad 
MODIS bit will be encountered every day. However, at a bit error rate of 10‘ 8 , 10,000 
bad bits will be encountered daily. The packets with uncorrectable errors should be 
flagged as such by the DHC. The MODIS science team may require a bit error rate of 
no worse than 10‘ 8 , or Grade II service of data transmission, whichever is lower, but 
10" 10 would be preferable. 

5.16 DATA COVERAGE 

Because MODIS data will be used to produce products with global coverage, missing 
packets will degrade the quality of the final product. Completeness to only the 99% level 
would result in a loss of 15 minutes of coverage; at 6.5 km per second, this is a 51° or 
about a 6,000-km swath along the orbit. The MODIS science team may require coverage 
to no less than 99.9%. Systematic coverage loss may be subject to different requirements 
than random coverage loss, perhaps to a factor of ten. 
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